home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
8_7_08.tro
< prev
next >
Wrap
Text File
|
1991-12-22
|
113KB
|
3,947 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v'|.5i'
.sp 2P
.LP
\fBRecommendation\ X.411\fR
.RT
.sp 2P
.ce 1000
\fBMESSAGE\ HANDLING\ SYSTEMS:\fR
.EF '% Fascicle\ VIII.7\ \(em\ Rec.\ X.411''
.OF '''Fascicle\ VIII.7\ \(em\ Rec.\ X.411 %'
.ce 0
.ce 1000
\fBMESSAGE\ TRANSFER\ SYSTEM:\ ABSTRACT\ SERVICE\fR
.ce 0
.sp 1P
.ce 1000
\fBDEFINITION\ AND\ PROCEDURES\fR
.FS
Recommendation X.411
and ISO 10021\(hy4, Information Processing Systems \(em Text Communication \(em
MOTIS \(em Message Transfer System: Abstract Service Definition and
Procedures, were developed in close collaboration and are technically
aligned, except for the differences noted in Annex\ C.
.FE
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.PP
The establishment in various countries of telematic services
and computer\(hybased store\(hyand\(hyforward message services in association
with
public data networks creates a need to produce standards to facilitate
international message exchange between subscribers to such services.
.sp 1P
.RT
.sp 2P
.LP
The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
the need for Message Handling systems;
.PP
(b)
the need to transfer messages of different types;
.PP
(c)
that Recommendation X.200 defines the reference model of open systems interconnection
for CCITT applications;
.PP
(d)
that Recommendations X.208, X.217, X.218 and X.219 provide the foundation
for CCITT applications;
.PP
(e)
that the X.500\(hyseries Recommendations define directory
systems;
.PP
(f
)
that Message Handling systems are defined in a
series of Recommendations: X.400, X.402, X.403, X.407, X.408, X.411, X.413
and X.419; and
.PP
(g)
that interpersonal messaging is defined in
RecommendationsX.420 and T.330,
.sp 1P
.LP
\fIunanimously declares\fR
.sp 9p
.RT
.PP
(1)
that the message transfer system (MTS) abstract service is defined in Section\
2;
.PP
(2)
that the message transfer agent (MTA) abstract service is defined in Section\
3;
.PP
(3)
that the procedures performed by message\(hytransfer\(hyagents (MTAs) to
ensure that correct distributed operation of the message transfer
system (MTS) are defined in Section\ 4.
\v'1P'
.sp 1P
.ce 1000
TABLE\ OF\ CONTENTS
.ce 0
.sp 1P
.LP
SECTION\ 1\ \(em\ \fIIntroduction\fR
.sp 1P
.RT
.sp 2P
.LP
0
Introduction
.sp 1P
.RT
.sp 1P
.LP
1
Scope
.sp 9p
.RT
.sp 1P
.LP
2
References
.sp 9p
.RT
.sp 1P
.LP
3
Definitions
.sp 9p
.RT
.sp 1P
.LP
4
Abbreviations
.sp 9p
.RT
.sp 1P
.LP
5
Conventions
.sp 9p
.RT
.LP
.sp 1
.bp
.sp 2P
.LP
SECTION\ 2\ \(em\ \fIMessage transfer system abstract service\fR
.sp 1P
.RT
.sp 1P
.LP
6
Message transfer system model
.sp 9p
.RT
.sp 1P
.LP
7
Message transfer system abstract service overview
.sp 9p
.RT
.sp 1P
.LP
8
Message transfer system abstract service definition
.sp 9p
.RT
.sp 1P
.LP
9
Message transfer system abstract syntax definition
.sp 9p
.RT
.sp 2P
.LP
SECTION\ 3\ \(em\ \fIMessage transfer agent abstract service\fR
.sp 1P
.RT
.sp 1P
.LP
10
Refined message transfer system model
.sp 9p
.RT
.sp 1P
.LP
11
Message transfer agent abstract service overview
.sp 9p
.RT
.sp 1P
.LP
12
Message transfer agent abstract service definition
.sp 9p
.RT
.sp 1P
.LP
13
Message transfer agent abstract syntax definition
.sp 9p
.RT
.sp 2P
.LP
SECTION\ 4\ \(em\ \fIProcedures for distributed operation of the MTS\fR
.sp 1P
.RT
.sp 1P
.LP
14
Procedures for distributed operation of the MTS
.sp 9p
.RT
.sp 1P
.LP
\fIAnnex\ A\fR \(em
Reference definition of MTS object identifiers
.sp 9p
.RT
.sp 1P
.LP
\fIAnnex\ B\fR \(em
Reference definition of MTS parameter upper bounds
.sp 9p
.RT
.sp 1P
.LP
\fIAnnex\ C\fR \(em
Differences between ISO/IEC and CCITT versions
.sp 9p
.RT
.LP
SECTION\ 1\ \(em\ INTRODUCTION
.sp 1P
.RT
.sp 2P
.LP
\fB0\fR \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation is one of a set of Recommendations defining
Message Handling in a distributed open systems environment.
.PP
Message Handling provides for the exchange of messages between users on
a store\(hyand\(hyforward basis. A message submitted by one user (the
\fIoriginator\fR ) is transferred through the message transfer system (MTS) and
delivered to one or more other users (the \fIrecipients\fR ).
.PP
The MTS comprises a number of message\(hytransfer\(hyagents (MTAs), which
transfer messages and deliver them to their intended recipients.
.PP
This Recommendation was developed jointly by CCITT and ISO. The
equivalent ISO document is ISO\ 10021\(hy4.
.RT
.sp 2P
.LP
\fB1\fR \fBScope\fR
.sp 1P
.RT
.PP
This Recommendation defines the abstract service provided by the
MTS (the MTS abstract service), and specifies the procedures to be performed
by MTAs to ensure the correct distributed operation of the MTS.
.PP
Recommendation X.402 identifies the other Recommendations which define
other aspects of Message Handling Systems.
.PP
Access to the MTS abstract service defined in this Recommendation may be
provided by the MTS access protocol (P3) defined in Recommendation\ X.419.
The distributed operation of the MTS defined in this Recommendation may be
provided by the use of the MTS transfer protocol (P1) also defined in
Recommendation\ X.419.
.bp
.PP
Section\ 2 of this Recommendation defines the MTS abstract service.
Paragraph\ 6 describes the message transfer system model. Paragraph\ 7
provides an overview of the MTS abstract service. Paragraph\ 8 defines
the semantics of the parameters of the MTS abstract service. Paragraph\
9 defines the
abstract syntax of the MTA abstract service.
.PP
Section\ 3 of this Recommendation defines the MTA abstract service.
Paragraph\ 10 refines the model of the MTS, first presented in \(sc\ 6,
to show that the MTS comprises a number of MTAs that interwork with one
another to provide the MTS abstract service. Paragraph\ 11 provides an
overview of the MTA abstract service. Paragraph\ 12 defines the semantics
of the parameters of the MTA
abstract service. Paragraph\ 13 defines the abstract\(hysyntax of the MTA
abstract service.
.PP
Section\ 4 of this Recommendation specifies the procedures performed by
MTAs to ensure the correct distributed operation of the MTS.
.PP
Annex A provides a reference definition of the MTS object identifiers cited
in the ASN.1 modules of this Recommendation.
.PP
Annex\ B provides a reference definition of the upper bounds of the
size constraints imposed upon variable length data types defined in ASN.1
modules in the body of this Recommendation.
.PP
Annex\ C identifies the technical differences between ISO/IEC and CCITT
versions of CCITT Recommendations X.411 and ISO/IEC 10021\(hy4.
.RT
.sp 2P
.LP
\fB2\fR \fBReferences\fR
.sp 1P
.RT
.PP
References are listed in Recommendation X.402.
.RT
.sp 2P
.LP
\fB3\fR \fBDefinitions\fR
.sp 1P
.RT
.PP
Definitions are listed in Recommendation X.402.
.RT
.sp 2P
.LP
\fB4\fR \fBAbbreviations\fR
.sp 1P
.RT
.PP
Abbreviations are listed in Recommendation X.402.
.RT
.sp 2P
.LP
\fB5\fR \fBConventions\fR
.sp 1P
.RT
.PP
This Recommendation uses the descriptive conventions described
below.
.RT
.sp 1P
.LP
5.1
\fITerms\fR
.sp 9p
.RT
.PP
Throughout this Recommendation, the words of defined terms and the names
and values of the parameters of the MTS abstract service and the MTA
abstract service, unless they are proper names, begin with a lower\(hycase
letter and are linked by a hyphen thus: defined\(hyterm. Proper names begin
with an
upper\(hycase letter and are not linked by a hyphen thus: Proper Name.
In \(sc\(sc\ 8
and\ 12, the names and values of the parameters of the MTS abstract service
and the MTA abstract service are printed in bold.
.RT
.sp 1P
.LP
5.2
\fIPresence of parameters\fR
.sp 9p
.RT
.PP
In the Tables of parameters in \(sc\(sc 8 and 12, the presence of each
parameter is qualified as follows:
.RT
.LP
\(em
Mandatory (M): A mandatory parameter shall always be
present.
.LP
\(em
Optional (O): An optional argument shall be present at the
direction of the invoker of the abstract\(hyoperation; an optional result
at the discretion of the performer of the abstract\(hyoperation.
.LP
\(em
Conditional (C): A conditional parameter shall be present
as defined by this [Recommendation/International Standard].
.PP
Where a conditional parameter shall be present due to some action on the
message, probe or report by the MTS, this is explicitly defined. The
presence of other conditional parameters is dependent on the presence of
those parameters in other abstract\(hyoperations (for example, the presence
of a
conditional argument of the Message\(hytransfer abstract\(hyoperation is
dependent on the presence of the same optional argument in the related
Message\(hysubmission
abstract\(hyoperation).
.sp 1P
.LP
5.3
\fIAbstract syntax definitions\fR
.sp 9p
.RT
.PP
This Recommendation defines the abstract\(hysyntax of the MTS abstract
service and the MTA abstract service using the abstract syntax notation
(ASN.1) defined in Recommendation\ X.208, and the abstract service definition
conventions defined in Recommendation\ X.407.
.PP
Where there are changes implied to the protocols defined in
Recommendation\ X.411 (1984), these are highlighted in the abstract syntax
definitions by means of
underlining
.
.bp
.RT
.LP
SECTION\ 2\ \(em\ MESSAGE TRANSFER SYSTEM ABSTRACT SERVICE
.sp 1P
.RT
.sp 2P
.LP
\fB6\fR \fBMessage transfer system model\fR
.sp 1P
.RT
.PP
Message Handling provides for the exchange of messages between
users on a store\(hyand\(hyforward basis. A message submitted by one user (the
\fIoriginator\fR ) is transferred through the message transfer system (MTS) and
delivered to one or more other users (the \fIrecipients\fR ).
.PP
The MTS is described using an abstract model in order to define the
services provided by the MTS as a whole \(em the MTS abstract service.
.PP
The MTS is modelled as an \fIobject\fR , whose overall behaviour can be
described without reference to its internal structure. The services provided
by the MTS object are made available at \fIports\fR . A type of port represents
a
particular view of the services provided by the MTS object.
.PP
A user of the MTS is also modelled as an object, which obtains the
services provided by the MTS through a port which is \fIpaired\fR with
an MTS port of the same type.
.PP
A type of port corresponds to a set of a \fIabstract\(hyoperations\fR \|
which can occur at the port; those which can be performed by the MTS object
(invoked by the MTS\(hyuser object), and those which can be invoked by
the MTS object
(performed by the MTS\(hyuser object).
.PP
A port may be symmetrical, in which case the set of operations
performed by the MTS object may also be invoked by the MTS object, and vice
versa. Otherwise, the port is asymmetrical, in which case the object is
said to be the \fIsupplier\fR or \fIconsumer\fR with respect to the type
of port. The terms
\fIsupplier\fR and \fIconsumer\fR are used only to distinguish between
the roles of a pair of ports in invoking or performing operations. The
assignment of the terms is usually intuitive when one object is providing
a service used by another
object; the service object (e.g.,\ the MTS) is usually regarded as being the
\fIsupplier\fR , and the user object (e.g.,\ an MTS\(hyuser object) is
usually regarded as being the \fIconsumer\fR .
.PP
Before objects can invoke operations on one another, they must be
bound into an abstract \fIassociation\fR . The binding of an assocation
between the objects establishes a relationship between the objects which
lasts until the
association is released. An association is always released by the initiator
of the association. The binding of an association establishes the \fIcredentials\fR
of the objects to interact, and the \fIapplication\(hycontext\fR and \fIsecurity\(hycontext\fR
of the association. The \fIapplication\(hycontext\fR of an association
may be one or more types of port paired between two objects.
.PP
The model presented is abstract. That is, it is not always possible
for an outside observer to identify the boundaries between objects, or to
decide on the moment or the means by which operations occur. However, in
some cases the abstract model will be \fIrealised\fR . For example, a pair
of objects
which communicate through paired ports may be located in different open
systems. In this case, the boundary between the objects is visible, the
ports are exposed, and the operations may be supported by instances of
OSI
communication.
.PP
The MTS object supports ports of three different types: a
\fIsubmission\(hyport\fR , a \fIdelivery\(hyport\fR and an \fIadministration\(hyport\fR
.
.PP
A submission\(hyport enables an MTS\(hyuser to submit messages to the MTS
for transfer and delivery to one or more recipient MTS\(hyusers, and to
probe the ability of the MTS to deliver a subject\(hymessage.
.PP
A delivery\(hyport enables an MTS\(hyuser to accept delivery of messages
from the MTS, and to accept reports on the delivery or non\(hydelivery
of messages and probes.
.PP
An administration\(hyport enables an MTS\(hyuser to change long term
parameters held by the MTS associated with message delivery, and enables
either the MTS or the MTS\(hyuser to change their \fIcredentials\fR with one
another.
.PP
A message submitted by one MTS\(hyuser via a submission\(hyport will
normally be delivered to one or more recipient MTS\(hyusers via delivery ports.
The originating MTS\(hyuser may elect to be notified of the delivery of
a message via its delivery\(hyport.
.PP
Figure 1/X.411 models the message transfer system (MTS).
.PP
Paragraph 7 provides an overview of the MTS Abstract
Service.
.bp
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 1/X.411, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB7\fR \fBMessage transfer system abstract service overview\fR
.sp 1P
.RT
.PP
This Recommendation defines the following services that comprise
the MTS abstract service:
.RT
.sp 1P
.LP
\fIMTS bind and unbind\fR
.sp 9p
.RT
.LP
a)
MTS\(hybind
.LP
b)
MTS\(hyunbind
.sp 1P
.LP
\fISubmission port abstract operations\fR
.sp 9p
.RT
.LP
c)
Message\(hysubmission
.LP
d)
Probe\(hysubmission
.LP
e)
Cancel\(hydeferred\(hydelivery
.LP
f
)
Submission\(hycontrol
.sp 1P
.LP
\fIDelivery port abstract operations\fR
.sp 9p
.RT
.LP
g)
Message\(hydelivery
.LP
h)
Report\(hydelivery
.LP
i)
Delivery\(hycontrol
.sp 1P
.LP
\fIAdministration port abstract operations\fR
.sp 9p
.RT
.LP
j)
Register
.LP
k)
Change\(hycredentials.
.sp 1P
.LP
7.1
\fIMTS bind and unbind\fR
.sp 9p
.RT
.PP
The \fBMTS\(hybind\fR enables either the MTS\(hyuser to establish an
association with the MTS, or the MTS to establish an association with the
MTS\(hyuser. Abstract\(hyoperations other than MTS\(hybind can only be
invoked in the
context of an established association.
.PP
The \fBMTS\(hyunbind\fR enables the release of an established association
by the initiator of the association.
.bp
.RT
.sp 1P
.LP
7.2
\fISubmission port\fR
.sp 9p
.RT
.PP
The
\fBmessage\(hysubmission\fR abstract\(hyoperation enables an
MTS\(hyuser to submit a message to the MTS for transfer and delivery to one or
more recipient MTS\(hyusers.
.PP
The
\fBprobe\(hysubmission\fR abstract\(hyoperation enables an MTS\(hyuser
to submit a probe in order to determine whether or not a message could
be
transferred and delivered to one or more recipient MTS\(hyusers if it were
to be submitted.
.PP
The
\fBcancel\(hydeferred\(hydelivery\fR abstract\(hyoperation enables an MTS\(hyuser
to request cancellation of a message previously submitted (for
deferred delivery) by invocation of the message\(hysubmission\(hyabstract\(hyoperation.
.PP
The
\fBsubmission\(hycontrol\fR abstract\(hyoperation enables the MTS to constrain
the use of the submission\(hyport abstract\(hyoperations by the MTS\(hyuser.
.PP
The
\fBmessage\(hysubmission\fR and \fBProbe\(hysubmission\fR
abstract\(hyoperations may cause subsequent invocation of the Report\(hydelivery
abstract\(hyoperation by the MTS.
.RT
.sp 1P
.LP
7.3
\fIDelivery port\fR
.sp 9p
.RT
.PP
The
\fBmessage\(hydelivery\fR abstract\(hyoperation enables the MTS to deliver
a message to the MTS\(hyuser.
.PP
The
\fBreport\(hydelivery\fR abstract\(hyoperation enables the MTS to
acknowledge to the MTS\(hyuser the outcome of a previous invocation of the
message\(hysubmission or probe\(hysubmission abstract\(hyoperations. For
the message\(hy
submission abstract\(hyoperation, the report\(hydelivery abstract\(hyoperation
indicates the delivery or non\(hydelivery of the submitted message. For the
probe\(hysubmission abstract\(hyoperation, the report\(hydelivery abstract\(hyoperation
indicates whether or not a message could be delivered if it were to be
submitted. The report\(hydelivery abstract\(hyoperation may also convey a
notification of physical\(hydelivery by a PDS.
.PP
The
\fBdelivery\(hycontrol\fR abstract\(hyoperation enables an MTS\(hyuser
to constrain the use of the delivery\(hyport abstract\(hyoperations by
the
MTS.
.RT
.sp 1P
.LP
7.4
\fIAdministration port\fR
.sp 9p
.RT
.PP
The
\fBregister\fR abstract\(hyoperation enables an MTS\(hyuser to
change long term parameters of the MTS\(hyuser held by the MTS, associated with
message delivery.
.PP
The
\fBchange\(hycredentials\fR abstract\(hyoperation enables either an MTS\(hyuser
to change its \fBcredentials\fR with the MTS, or the MTS to change its
\fBcredentials\fR with the MTS\(hyuser.
.RT
.sp 2P
.LP
\fB8\fR \fBMessage transfer system abstract service definition\fR
.sp 1P
.RT
.PP
This section defines the semantics of the parameters of the MTS
abstract service.
.PP
Paragraph\ 8.1 defines the MTS\(hybind and MTS\(hyunbind. Paragraph\ 8.2
defines the submission\(hyport. Paragraph\ 8.3 defines the delivery\(hyport.
Paragraph\ 8.4 defines the administration\(hyport. Paragraph\ 8.5 defines some
common parameter types.
.PP
The abstract\(hysyntax of the MTS abstract service is defined in
\(sc\ 9.
.RT
.sp 1P
.LP
8.1
\fIMTS\(hybind and MTS\(hyunbind\fR
.sp 9p
.RT
.PP
This section defines the MTS\(hybind and MTS\(hyunbind used to establish
and release associations between an MTS\(hyuser and the MTS.
.RT
.sp 1P
.LP
8.1.1
\fIAbstract\(hybind and abstract\(hyunbind\fR
.sp 9p
.RT
.PP
This section defines the following abstract\(hybind and
abstract\(hyunbind operations:
.RT
.LP
a)
MTS\(hybind
.LP
b)
MTS\(hyunbind.
.sp 1P
.LP
8.1.1.1
\fIMTS\(hybind\fR
.sp 9p
.RT
.PP
The MTS\(hybind enables an MTS\(hyuser to establish an association with
the MTS, or the MTS to establish an association with an MTS\(hyuser.
.PP
The MTS\(hybind establishes the \fBcredentials\fR of an MTS\(hyuser and
the MTS to interact, and the \fBapplication\(hycontext\fR and \fBsecurity\(hycontext\fR
of the
association. An association can only be released by the initiator of that
association (using MTS\(hyunbind).
.bp
.PP
Abstract\(hyoperations other than MTS\(hybind can only be invoked in the
context of an established association.
.PP
The successful completion of the MTS\(hybind signifies the establishment
of an association.
.PP
The disruption of the MTS\(hybind by a bind\(hyerror indicates that an
association has not been established.
.RT
.sp 1P
.LP
8.1.1.1.1\ \ \fIArguments\fR
.sp 9p
.RT
.PP
Table\ 1/X.411 lists the arguments of the MTS\(hybind, and for each
argument qualifies its presence and indicates the clause in which the argument
is defined.
.RT
.ce
\fBH.T. [T1.411]\fR
.ce
TABLE\ 1/X.411
.ce
\fBMTS\(hybind arguments\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(36p) .
Argument Presence Clause
_
.T&
lw(90p) | lw(30p) | lw(36p) .
\fIBind arguments\fR
.T&
lw(90p) | cw(30p) | cw(36p) .
Initiator\(hyname M 8.1.1.1.1.1
.T&
lw(90p) | cw(30p) | cw(36p) .
Initiator\(hycredentials M 8.1.1.1.1.2
.T&
lw(90p) | cw(30p) | cw(36p) .
Security\(hycontext O 8.1.1.1.1.3
.T&
lw(90p) | cw(30p) | cw(36p) .
Messages\(hywaiting O 8.1.1.1.1.4
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 1/X.411 [T1.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.1.1.1.1.1\ \
\fIInitiator\(hyname\fR
.sp 9p
.RT
.PP
This argument contains a name for the initiator of the association. It
shall be generated by the initiator of the association.
.PP
If the initiator is an MTS\(hyuser, the name is the \fBOR\(hyname\fR of the
MTS\(hyuser, which is registered with the MTS (see \(sc\ 8.4.1.1.1.1). The
\fBinitiator\(hyname\fR shall contain the \fBOR\(hyaddress\fR , and may
optionally also
contain the \fBdirectory\(hyname\fR , of the MTS\(hyuser
(\fBOR\(hyaddress\(hyand\(hyoptional\(hydirectory\(hyname\fR ). For secure
messaging, when an MS is involved, the \fBinitiator\(hyname\fR may also
indicate whether the initiator is a UA or an MS.
.PP
If the initiator is the MTS (or an MTA \(em see \(sc\ 11), the name is an
\fBMTA\(hyname\fR , which is known to the MTS\(hyuser.
.RT
.sp 1P
.LP
8.1.1.1.1.2\ \
\fIInitiator\(hycredentials\fR
.sp 9p
.RT
.PP
This argument contains the \fBcredentials\fR of the initiator of the
association. It shall be generated by the initiator of the association.
.PP
The \fBinitiator\(hycredentials\fR may be used by the responder to
authenticate the identity of the initiator (see Recommendation\ X.509).
.PP
If only simple\(hyauthentication is used, the \fBinitiator\(hycredentials\fR
comprise a simple \fBpassword\fR associated with the \fBinitiator\(hyname\fR .
.PP
If strong\(hyauthentication is used, the \fBinitiator\(hycredentials\fR
comprise an \fBinitiator\(hybind\(hytoken\fR and, optionally, an \fBinitiator\(hycertificate\fR
.
.PP
The
\fBinitiator\(hybind\(hytoken\fR is a token generated by the
initiator of the association. If the \fBinitiator\(hybind\(hytoken\fR is an
\fBasymmetric\(hytoken\fR , the \fBsigned\(hydata\fR comprises a \fBrandom
number\fR . The
\fBencrypted\(hydata\fR of an \fBasymmetric\(hytoken\fR may be used to
convey secret
security\(hyrelevant information (e.g.,\ one or more symmetric\(hyencryption\(hykeys)
used to secure the association, or may be absent from the
\fBinitiator\(hybind\(hytoken\fR .
.bp
.PP
\fR
.PP
The
\fBinitiator\(hycertificate\fR is a \fBcertificate\fR of the
initiator of the association, generated by a trusted source (e.g.,\ a
certification\(hyauthority). It may be supplied by the initiator of the
association, if the \fBinitiator\(hybind\(hytoken\fR is an \fBasymmetric\(hytoken\fR
. The
\fBinitiator\(hycertificate\fR may be used to convey a verified copy of the
public\(hyasymmetric\(hyencryption\(hykey (\fBsubject\(hypublic\(hykey\fR
) of the initiator of the association. The initiator's public\(hyasymmetric\(hyencryption\(hykey
may be used by
the responder to compute the \fBresponder\(hybind\(hytoken\fR . If the
responder is known to have, or have access to, the initiator's \fBcertificate\fR
(e.g.,\ via the
change\(hycredentials abstract\(hyoperation, or via the directory), the
\fBinitiator\(hycertificate\fR may be omitted.
.RT
.sp 1P
.LP
8.1.1.1.1.3\ \
\fISecurity\(hycontext\fR
.sp 9p
.RT
.PP
This argument identifies the \fBsecurity\(hycontext\fR that the initiator
of the association proposes to operate at. It may be generated by the initiator
of the association.
.PP
The \fBsecurity\(hycontext\fR comprises one or more \fBsecurity\(hylabels\fR
that
define the sensitivity of interactions that may occur between the MTS\(hyuser
and the MTS for the duration of the association, in line with the security\(hypolicy
in force. The \fBsecurity\(hycontext\fR shall be one that is allowed by
the registered \fBuser\(hysecurity\(hylabels\fR of the MTS\(hyuser and
by the \fBsecurity\(hylabels\fR associated with the MTA of the MTS.
.PP
Once established, the \fBsecurity\(hycontext\fR of the submission\(hyport and
delivery\(hyport can be temporarily restricted using the submission\(hycontrol
(see \(sc\ 8.2.1.4.5) and delivery\(hycontrol (see \(sc\ 8.3.1.3.1.7) abstract\(hyoperation,
respectively.
.PP
If \fBsecurity\(hycontexts\fR are not established between the MTS\(hyuser and
the MTS, the sensitivity of interactions that may occur between the MTS\(hyuser
and the MTS may be at the discretion of the invoker of an
abstract\(hyoperation.
.RT
.sp 1P
.LP
8.1.1.1.1.4\ \ \fIMessages\(hywaiting\fR
.sp 9p
.RT
.PP
This argument indicates that the number of messages and total
number of octets waiting to be delivered by the MTS to the MTS\(hyuser,
for each \fBpriority\fR . It may be generated by the initiator of the association.
.PP
This argument shall only be present when the MTS is initiating an
association with an MTS\(hyuser, and when the MTS\(hyuser subscribes to
the hold for delivery element\(hyof\(hyservice (defined in Recommendation\
X.400).
.RT
.sp 1P
.LP
8.1.1.1.2\ \ \fIResults\fR
.sp 9p
.RT
.PP
Table 2/X.411 lists the results of the MTS\(hybind, and for each
result qualifies its presence and indicates the clause in which the result
is defined.
.RT
.ce
\fBH.T. [T2.411]\fR
.ce
TABLE\ 2/X.411
.ce
\fBMTS\(hybind results\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(36p) .
Result Presence Clause
_
.T&
lw(90p) | lw(30p) | lw(36p) .
\fIBind results\fR
.T&
lw(90p) | cw(30p) | cw(36p) .
Responder\(hyname M 8.1.1.1.2.1
.T&
lw(90p) | cw(30p) | cw(36p) .
Responder\(hycredentials M 8.1.1.1.2.2
.T&
lw(90p) | cw(30p) | cw(36p) .
Messages\(hywaiting O 8.1.1.1.2.3
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 2/X.411 [T2.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.1.1.1.2.1\ \
\fIResponder\(hyname\fR
.sp 9p
.RT
.PP
This argument contains a name for the responder of the association. It
shall be generated by the responder of the association.
.PP
If the responder is an MTS\(hyuser, the name is the \fBOR\(hyname\fR of the
MTS\(hyuser, which is registered with the MTS (see \(sc\ 8.4.1.1.1.1). The
\fBresponder\(hyname\fR shall contain the \fBOR\(hyaddress\fR , and may
optionally also
contain the \fBdirectory\(hyname\fR , of the MTS\(hyuser
(\fBOR\(hyaddress\(hyand\(hyoptional\(hydirectory\(hyname\fR ). For secure
messaging, when an MS is involved, the \fBresponder\(hyname\fR may also
indicate whether the initiator is a UA or an MS.
.PP
If the responder is the MTS (or an MTA \(em see \(sc\ 11), the name is an
\fBMTA\(hyname\fR , which is known to the MTS\(hyuser.
.bp
.RT
.sp 1P
.LP
8.1.1.1.2.2\ \
\fIResponder\(hycredentials\fR
.sp 9p
.RT
.PP
This argument contains the \fBcredentials\fR of the responder of the
association. It shall be generated by the responder of the association.
.PP
The \fBresponder\(hycredentials\fR may be used by the initiator to
authenticate the identity of the responder (see Recommendation\ X.509).
.PP
If only simple\(hyauthentication is used, the \fBresponder\(hycredentials\fR
comprise a simple \fBpassword\fR associated with the \fBresponder\(hyname\fR .
.PP
If strong\(hyauthentication is used, the \fBresponder\(hycredentials\fR
comprise a \fBresponder\(hybind\(hytoken\fR . The
\fBresponder\(hybind\(hytoken\fR is a \fBtoken\fR
generated by the responder of the association. The \fBresponder\(hybind\(hytoken\fR
shall be the same type of \fBtoken\fR as the \fBinitiator\(hybind\(hytoken\fR
. If the
\fBresponder\(hybind\(hytoken\fR is an \fBasymmetric\(hytoken\fR , the
\fBsigned\(hydata\fR comprises a \fBrandom\(hynumber\fR (which may be related
to the \fBrandom\(hynumber\fR supplied in the
\fBinitiator\(hybind\(hytoken\fR ). The \fBencrypted\(hydata\fR of an \fBassymetric\(hytoken\fR
may be used to convey secret security\(hyrelevant information (e.g.,\ one
or more
symmetric\(hyencryption\(hykeys) used to secure the association, or may
be absent
from the \fBresponder\(hybind\(hytoken\fR .
.RT
.sp 1P
.LP
8.1.1.1.2.3\ \
\fIMessages\(hywaiting\fR
.sp 9p
.RT
.PP
This argument indicates the number of messages and total number of octets
waiting to be delivered by the MTS to the MTS\(hyuser, for each \fBpriority\fR
. It may be generated by the responder of the association.
.PP
This argument shall only be present when the MTS is responding to an association
initiated by an MTS\(hyuser, and when the MTS\(hyuser subscribes to the
hold for delivery element\(hyof\(hyservice (defined in Recommendation\
X.400).
.RT
.sp 1P
.LP
8.1.1.1.3\ \
\fIBind\(hyerrors\fR
.sp 9p
.RT
.PP
The bind\(hyerrors that may disrupt the MTS\(hybind are defined in
\(sc\ 8.1.2.
.RT
.sp 1P
.LP
8.1.1.2
\fIMTS\(hyunbind\fR
.sp 9p
.RT
.PP
The MTS\(hyunbind enables the release of an established association by
the initiator of the association.
.RT
.sp 1P
.LP
8.1.1.2.1\ \ \fIArguments\fR
.sp 9p
.RT
.PP
The MTS\(hyunbind has no arguments.
.RT
.sp 1P
.LP
8.1.1.2.2\ \ \fIResults\fR
.sp 9p
.RT
.PP
The MTS\(hyunbind returns an empty result as indication of release of the
association.
.RT
.sp 1P
.LP
8.1.1.2.3\ \ \fIUnbind\(hyerrors\fR
.sp 9p
.RT
.PP
There are no unbind\(hyerrors that may disrupt the MTS\(hyunbind.
.RT
.sp 1P
.LP
8.1.2
\fIBind\(hyerrors\fR
.sp 9p
.RT
.PP
This section defines the following bind\(hyerrors:
.RT
.LP
a)
Authentication\(hyerror
.LP
b)
Busy
.LP
c)
Unacceptable\(hydialogue\(hymode
.LP
d)
Unacceptable\(hysecurity\(hycontext.
.sp 1P
.LP
8.1.2.1
\fIAuthentication\(hyerror\fR
.sp 9p
.RT
.PP
The authentication\(hyerror bind\(hyerror reports that an association
cannot be established due to an authentication error; the initiator's
\fBcredentials\fR are not acceptable or are improperly specified.
.PP
The authentication\(hyerror bind\(hyerror has no parameters.
.RT
.sp 1P
.LP
8.1.2.2
\fIBusy\fR
.sp 9p
.RT
.PP
The busy bind\(hyerror reports that an association cannot be
established because the responder is busy.
.PP
The busy\(hybind\(hyerror has no parameters.
.bp
.RT
.sp 1P
.LP
8.1.2.3
\fIUnacceptable\(hydialogue\(hymode\fR
.sp 9p
.RT
.PP
The unacceptable\(hydialogue\(hymode bind\(hyerror reports that the
dialogue\(hymode proposed by the initiator of the association is unacceptable
to the responder (see Recommendation\ X.419).
.PP
The unacceptable\(hydialogue\(hymode bind\(hyerror has no parameters.
.RT
.sp 1P
.LP
8.1.2.4
\fIUnacceptable\(hysecurity\(hycontext\fR
.sp 9p
.RT
.PP
The unacceptable\(hysecurity\(hycontext bind\(hyerror reports that the
\fBsecurity\(hycontext\fR proposed by the initiator of the association
is unacceptable to the responder.
.PP
The unacceptable\(hysecurity\(hycontext bind\(hyerror reports that the
\fBsecurity\(hycontext\fR proposed by the initiator of the association
is unacceptable to the responder.
.PP
The unacceptable\(hysecurity\(hycontext bind\(hyerror has no parameters.
.RT
.sp 1P
.LP
8.2
\fISubmission port\fR
.sp 9p
.RT
.PP
This section defines the abstract\(hyoperations and abstract\(hyerrors
which occur at a submission\(hyport.
.RT
.sp 1P
.LP
8.2.1
\fIAbstract\(hyoperations\fR
.sp 9p
.RT
.PP
This section defines the following submission\(hyport
abstract\(hyoperations.
.RT
.LP
a)
Message\(hysubmission
.LP
b)
Probe\(hysubmission
.LP
c)
Cancel\(hydeferred\(hydelivery
.LP
d)
Submission\(hycontrol.
.sp 1P
.LP
8.2.1.1
\fIMessage\(hysubmission\fR
.sp 9p
.RT
.PP
The message\(hysubmission abstract\(hyoperation enables an MTS\(hyuser to
submit a message to the MTS for transfer and delivery to one or more recipient
MTS\(hyusers.
.PP
The successful completion of the abstract\(hyoperation signifies that the
MTS has accepted responsibility for the message (but not that it has yet
delivered it to its intended recipients).
.PP
The disruption of the abstract\(hyoperation by an abstract\(hyerror
indicates that the MTS cannot assume responsibility for the message.
.RT
.sp 1P
.LP
8.2.1.1.1\ \ \fIArguments\fR
.sp 9p
.RT
.PP
Table 3/X.411 lists the arguments of the message\(hysubmission
abstract\(hyoperation, and for each argument qualifies its presence and
identifies the clause in which the argument is defined.
.RT
.sp 1P
.LP
8.2.1.1.1.1\ \
\fIOriginator\(hyname\fR
.sp 9p
.RT
.PP
This argument contains the \fBOR\(hyname\fR of the originator of the
message. It shall be generated by the originating MTS\(hyuser.
.PP
The \fBoriginator\(hyname\fR contains the \fBOR\(hyname\fR of an individual
originator, i.e., it shall not contain the \fBOR\(hyname\fR of a DL.
.RT
.sp 1P
.LP
8.2.1.1.1.2\ \
\fIRecipient\(hyname\fR
.sp 9p
.RT
.PP
This argument contains the \fBOR\(hyname\fR of a recipient of the message.
It shall be generated by the originator of the message. A different value
of
this argument shall be specified for each recipient of the message.
.PP
The \fBrecipient\(hyname\fR contains the \fBOR\(hyname\fR of an individual
recipient or DL.
.RT
.sp 1P
.LP
8.2.1.1.1.3\ \
\fIAlternate\(hyrecipient\(hyallowed\fR
.sp 9p
.RT
.PP
This argument indicates whether the message may be delivered to an alternate\(hyrecipient
assigned by the recipient\(hyMD, if the specified
\fBrecipient\(hyname\fR does not identify an MTS\(hyuser. It may be generated
by the
originator of the message.
.PP
This argument may have one of the following values:
\fBalternate\(hyrecipient\(hyallowed\fR or \fBalternate\(hyrecipient\(hy\fR
\fBprohibited\fR .
.bp
.RT
.ce
\fBH.T. [T3.411]\fR
.ce
TABLE\ 3/X.411
.ce
\fBMessage\(hysubmission arguments\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(114p) | cw(30p) | cw(36p) .
Argument Presence Clause
_
.T&
lw(114p) | lw(30p) | lw(36p) .
\fIOriginator argument\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
Originator\(hyname M 8.2.1.1.1.1\
.T&
lw(114p) | lw(30p) | lw(36p) .
\fIRecipient arguments\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
Recipient\(hyname M 8.2.1.1.1.2\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Alternate\(hyrecipient\(hyallowed
T} O 8.2.1.1.1.3\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Recipient\(hyreassignment\(hyprohibited
T} O 8.2.1.1.1.4\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Originator\(hyrequested\(hyalternate\(hyrecipient
T} O 8.2.1.1.1.5\
.T&
lw(114p) | cw(30p) | cw(36p) .
DL\(hyexpansion\(hyprohibited O 8.2.1.1.1.6\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Disclosure\(hyof\(hyrecipients
T} O 8.2.1.1.1.7\
.T&
lw(114p) | lw(30p) | lw(36p) .
\fIPriority argument\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
Priority O 8.2.1.1.1.8\
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIConversion arguments\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Implicit\(hyconversion\(hyprohibited
T} O 8.2.1.1.1.9\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Conversion\(hywith\(hyloss\(hyprohibited
T} O 8.2.1.1.1.10
.T&
lw(114p) | cw(30p) | cw(36p) .
Explicit\(hyconversion O 8.2.1.1.1.11
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIDelivery time arguments\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
Deferred\(hydelivery\(hytime O 8.2.1.1.1.12
.T&
lw(114p) | cw(30p) | cw(36p) .
Latest\(hydelivery\(hytime O 8.2.1.1.1.13
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIDelivery method argument\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Requested\(hydelivery\(hymethod
T} O 8.2.1.1.1.14
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIPhysical delivery arguments\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Physical\(hyforwarding\(hyprohibited
T} O 8.2.1.1.1.15
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Physical\(hyforwarding\(hyaddress\(hyrequest
T} O 8.2.1.1.1.16
.T&
lw(114p) | cw(30p) | cw(36p) .
Physical\(hydelivery\(hymodes O 8.2.1.1.1.17
.T&
lw(114p) | cw(30p) | cw(36p) .
Registered\(hymail\(hytype O 8.2.1.1.1.18
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Recipient\(hynumber\(hyfor\(hyadvice
T} O 8.2.1.1.1.19
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Physical\(hyrendition\(hyattributes
T} O 8.2.1.1.1.20
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Originator\(hyreturn\(hyaddress
T} O 8.2.1.1.1.21
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIReport request arguments\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Originator\(hyreport\(hyrequest
T} M 8.2.1.1.1.22
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hyreturn\(hyrequest O 8.2.1.1.1.23
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Physical\(hydelivery\(hyreport\(hyrequest
T} O 8.2.1.1.1.24
.T&
lw(114p) | lw(30p) | lw(36p) .
\fISecurity arguments\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
Originator\(hycertificate O 8.2.1.1.1.25
.T&
lw(114p) | cw(30p) | cw(36p) .
Message\(hytoken O 8.2.1.1.1.26
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Content\(hyconfidentiality\(hyalgorithm\(hyidentifier
T} O 8.2.1.1.1.27
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hyintegrity\(hycheck O 8.2.1.1.1.28
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Message\(hyorigin\(hyauthentication\(hycheck
T} O 8.2.1.1.1.29
.T&
lw(114p) | cw(30p) | cw(36p) .
Message\(hysecurity\(hylabel O 8.2.1.1.1.30
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Proof\(hyof\(hysubmission\(hyrequest
T} O 8.2.1.1.1.31
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Proof\(hyof\(hydelivery\(hyrequest
T} O 8.2.1.1.1.32
.T&
lw(114p) | lw(30p) | lw(36p) .
\fIContent arguments\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Original\(hyencoded\(hyinformation\(hytypes
T} O 8.2.1.1.1.33
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hytype M 8.2.1.1.1.34
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hyidentifier O 8.2.1.1.1.35
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hycorrelator O 8.2.1.1.1.36
.T&
lw(114p) | cw(30p) | cw(36p) .
Content M 8.2.1.1.1.37
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 3/X.411 [T3.411], p. 4\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
If this argument has the value \fBalternate\(hyrecipient\(hyallowed\fR
and the \fBrecipient\(hyname\fR (specified by the originator of the message,
or added by DL\(hyexpansion, or substituted by redirection to the
\fBrecipient\(hyassigned\(hyalternate\(hyrecipient\fR or the
\fBoriginator\(hyrequested\(hyalternate\(hyrecipient\fR , or present by
any combination of
redirection and expansion) does not identify an MTS\(hyuser, the message may be
redirected to an alternate\(hyrecipient assigned by the recipient\(hyMD
to receive
such messages. If no such alternate\(hyrecipient has been assigned by the
recipient\(hyMD, or if this argument has the value \fB
alternate\(hyrecipient\(hyprohibited\fR , a non\(hydelivery report shall be
generated.
.PP
In the absence of this argument, the default
\fBalternate\(hyrecipient\(hyprohibited\fR shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.4\ \
\fIRecipient\(hyreassignment\(hyprohibited\fR
.sp 9p
.RT
.PP
This argument indicates whether the message may be reassigned to a \fBrecipient\(hyassigned\(hyalternate\(hyrecipient\fR
registered by the intended\(hyrecipient. It may be generated by the originator
of the message.
.PP
This argument may have one of the following values:
\fBrecipient\(hyreassignment\(hyprohibited\fR or \fBrecipient\(hyreassignment\(hyallowed\fR
.
.PP
If this argument has the value \fBrecipient\(hyreassignment\(hyallowed\fR and
the intended\(hyrecipient has registered a
\fBrecipient\(hyassigned\(hyalternate\(hyrecipient\fR , the message shall
be redirected to
the \fBrecipient\(hyassigned\(hyalternate\(hyrecipient\fR .
.PP
If this argument has the value \fBrecipient\(hyreassignment\(hyprohibited\fR
and the intended\(hyrecipient has registered a
\fBrecipient\(hyassigned\(hyalternate\(hyrecipient\fR , then if an
\fBoriginator\(hyrequested\(hyalternate\(hyrecipient\fR has been specified
by the
originator of the message, the message shall be redirected to the
\fBoriginator\(hyrequested\(hyalternate\(hyrecipient\fR , or if no
\fBoriginator\(hyrequested\(hyalternate\(hyrecipient\fR has been specified
by the originator of the message, a non\(hydelivery\(hyreport shall be
generated.
.PP
In the absence of this argument, the default
\fBrecipient\(hyreassignment\(hyallowed\fR shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.5\ \
\fIOriginator\(hyrequested\(hyalternate\(hyrecipient\fR
.sp 9p
.RT
.PP
This argument contains the \fBOR\(hyname\fR of the alternate\(hyrecipient
requested by the originator of the message. It may be generated by the
originator of the message. A different value of this argument may be specified
for each recipient of the message.
.PP
The \fBoriginator\(hyrequested\(hyalternate\(hyrecipient\fR contains the
\fBOR\(hyname\fR of an individual, or DL, alternate\(hyrecipient.
.PP
If this argument is present and delivery of the message to the
\fBrecipient\(hyname\fR (specified by the originator of the message, or
added by
DL\(hyexpansion, or substituted by redirection to the
\fBoriginator\(hyrequested\(hyalternate\(hyrecipient\fR specified by this
argument.
.PP
If an \fBoriginator\(hyrequested\(hyalternate\(hyrecipient\fR has been
specified by the originator of the message, this message shall be redirected
to that
alternate recipient in preference to one assigned by the
recipient\(hyMD.
.RT
.sp 1P
.LP
8.2.1.1.1.6\ \
\fIDL\(hyexpansion\(hyprohibited\fR
.sp 9p
.RT
.PP
This argument indicates whether DL\(hyexpansion within an MTS shall
occur for any \fBrecipient\(hyname\fR which denotes a DL. It may be generated
by the originator of the message.
.PP
This argument may have one of the following values:
\fBDL\(hyexpansion\(hyprohibited\fR or \fBDL\(hyexpansion\(hyallowed\fR .
.PP
In the absence of this argument, the default \fBDL\(hyexpansion\(hyallowed\fR
shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.7\ \
\fIDisclosure\(hyof\(hyrecipients\fR
.sp 9p
.RT
.PP
This argument indicates whether the \fBrecipient\(hyname\fR of all
recipients are to be indicated to each recipient MTS\(hyuser when the message
is delivered. It may be generated by the originator of the message.
.PP
This argument may have one of the following
values: \fBdisclosure\(hyof\(hyrecipients\(hyallowed\fR or
\fBdisclosure\(hyof\(hy\fR
\fBrecipients\(hyprohibited\fR .
.PP
In the absence of this argument, the default
\fBdisclosure\(hyof\(hyrecipients\(hyprohibited\fR shall be assumed.
.bp
.RT
.sp 1P
.LP
8.2.1.1.1.8\ \
\fIPriority\fR
.sp 9p
.RT
.PP
This argument specifies the relative priority of the message:
\fBnormal\fR , \fBnon\(hyurgent\fR or \fBurgent\fR . It may be generated
by the originator of
the message.
.PP
In the absence of this argument, a default \fBpriority\fR of \fBnormal\fR
shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.9\ \
\fIImplicit\(hyconversion\(hyprohibited\fR
.sp 9p
.RT
.PP
This argument indicates whether implicit\(hyconversion may be
performed on the message \fBcontent\fR . It may be generated by the originator
of
the message.
.PP
This argument may have one of the following values:
\fBimplicit\(hyconversion\(hyprohibited\fR or \fBimplicit\(hyconversion\(hyallowed\fR
.
.PP
In the absence of this argument, the default
\fBimplicit\(hyconversion\(hyallowed\fR shall be assumed.
.PP
See also \(sc\ 8.2.1.1.1.10.
.RT
.sp 1P
.LP
8.2.1.1.1.10\ \
\fIConversion\(hywith\(hyloss\(hyprohibited\fR
.sp 9p
.RT
.PP
This argument indicates whether \fBencoded\(hyinformation\(hytype\fR
conversion(s) may be carried out on the message \fBcontent\fR , if such
conversion(s) would result in loss of information. Loss of information is
defined in Recommendation\ X.408. It may be generated by the originator
of the message.
.PP
This argument may have one of the following values:
\fBconversion\(hywith\(hyloss\(hyprohibited\fR or \fBconversion\(hywith\(hyloss\(hyallowed\fR
.
.PP
In the absence of this argument, the default
\fBconversion\(hywith\(hyloss\(hyallowed\fR shall be assumed.
.PP
The combined effect of the \fBimplicit\(hyconversion\(hyprohibited\fR and
\fBconversion\(hywith\(hyloss\(hyprohibited\fR arguments relate to implicit\(hyconversion
only and is defined in Table\ 4/X.411.
.RT
.ce
\fBH.T. [T4.411]\fR
.ce
TABLE\ 4/X.411
.ce
\fBCombined effect of conversion arguments\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(60p) | cw(60p) | cw(60p) .
Implicit conversion Conversion with loss Combined effect
_
.T&
lw(60p) | lw(60p) | lw(60p) .
allowed with\(hyloss\(hyallowed allowed
.T&
lw(60p) | lw(60p) | lw(60p) .
allowed with\(hyloss\(hyprohibited with\(hyloss\(hyprohibited
.T&
lw(60p) | lw(60p) | lw(60p) .
prohibited with\(hyloss\(hyallowed prohibited
.T&
lw(60p) | lw(60p) | lw(60p) .
prohibited with\(hyloss\(hyprohibited prohibited
_
.TE
.nr PS 9
.RT
.ad r
\fBTabeau 4/X.411 [T4.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.2.1.1.1.11\ \
\fIExplicit\(hyconversion\fR
.sp 9p
.RT
.PP
This argument indicates the type of conversion of the message
\fBcontent\fR explicitly requested by the originator for the recipient.
It may be generated by the originator of the message. A different value
of this argument may be specified for each recipient of the message.
.PP
This argument may have one of the following values:
\fBno\(hyexplicit\(hyconversion\fR , \fBia5\(hytext\(hyto\(hyteletex\fR
, \fBteletex\(hyto\(hytelex\fR ,
\fBtelex\(hyto\(hyia5\(hytext\fR , \fBtelex\(hyto\(hyteletex\fR , \fBtelex\(hyto\(hyg4\(hyclass\(hy1\fR
,
\fBtelex\(hyto\(hyvideotex\fR , \fBia5\(hytext\(hyto\(hytelex\fR , \fBtelex\(hyto\(hyg3\(hyfacsimile\fR
,
\fBia5\(hytext\(hyto\(hyg3\(hyfacsimile\fR , \fBia5\(hytext\(hyto\(hyg4\(hyclass\(hy1\fR
, \fBia5\(hytext\(hyto\(hyvideotex\fR , \fBteletex\(hyto\(hyia5\(hytext\fR
, \fBteletex\(hyto\(hyg3\(hyfacsimile\fR , \fBteletex\(hyto\(hyg4\(hyclass\(hy1\fR
,
\fBteletex\(hyto\(hyvideotex\fR ,
\fBvideotex\(hyto\(hytelex\fR , \fBvideotex\(hyto\(hyia5\(hytext\fR , or
\fBvideotex\(hyto\(hyteletex\fR . Other
types of \fBexplicit\(hyconversion\fR may be defined by future versions of this
Recommendation. \fBExplicit\(hyconversion\fR shall be performed as specified in
Recommendation\ X.408.
.PP
In the absence of this argument, the default \fBno\(hyexplicit conversion\fR
shall be assumed.
.PP
\fINote\fR \ \(em\ When specified for a recipient DL, \fBexplicit\(hyconversion\fR
applies to all members of the DL.
.bp
.RT
.sp 1P
.LP
8.2.1.1.1.12\ \
\fIDeferred\(hydelivery\(hytime\fR
.sp 9p
.RT
.PP
This argument specifies the \fBtime\fR before which the message should
not be delivered to the recipient(s). It may be generated by the originator
of the message.
.RT
.sp 1P
.LP
8.2.1.1.1.13\ \
\fILatest\(hydelivery\(hytime\fR
.sp 9p
.RT
.PP
This argument contains the \fBtime\fR after which the message should
not be delivered to the recipient(s). It may be generated by the originator
of the message.
.PP
The handling of non\(hydelivery because of \fBlatest\(hydelivery\(hytime\fR is
described in \(sc\ 14.3.2.4.
.RT
.sp 1P
.LP
8.2.1.1.1.14\ \
\fIRequested\(hydelivery\(hymethod\fR
.sp 9p
.RT
.PP
This argument indicates the requested method of delivery of the
message to the recipient. It may be generated by the originator of the
message. A different value of this argument may be specified for each recipient
of the message.
.PP
This argument may have one or more of the following values:
\fBany\(hydelivery\(hymethod\fR , \fBmhs\(hydelivery\fR , \fBphysical\(hydelivery\fR
, \fBteletex\(hydelivery\fR , \fBg3\(hyfacsimile\(hydelivery\fR , \fBg4\(hyfacsimile\(hydelivery\fR
, \fBia5\(hyterminal\(hydelivery\fR ,
\fBvideotex\(hydelivery\fR or \fBtelephone\(hydelivery\fR .
.PP
If more than one value of this argument is specified for a recipient, the
sequence of the values shall be assumed to imply the originator's order
of preference of delivery\(hymethods.
.PP
In the absence of this argument, the default \fBany\(hydelivery\(hymethod\fR
shall be assumed.
.PP
If the \fBrecipient\(hyname\fR generated by the originator of the message
contains a \fBdirectory\(hyname\fR but omits an \fBOR\(hyaddress\fR , the
MTS may use the
\fBrequested\(hydelivery\(hymethod\fR as an indication of which form of
\fBOR\(hyaddress\fR the \fBdirectory\(hyname\fR should be mapped to by
the MTS (e.g.,\ using the Directory). If a form of \fBOR\(hyaddress\fR
appropriate to a \fBrequested\(hydelivery\(hymethod\fR cannot be found,
a \fBrecipient\(hyimproperly\(hyspecified\fR abstract error shall be returned
to the originator of the message.
.PP
If the \fBrecipient\(hyname\fR generated by the originator of the message
contains an \fBOR\(hyaddress\fR of a form not appropriate to a
\fBrequested\(hydelivery\(hymethod\fR , a non\(hydelivery report shall
be returned to the
originator of the message.
.PP
If the originator\(hysupplied \fBrequested\(hydelivery\(hymethod\fR conflicts
with the recipient's preferred delivery\(hymethod (e.g.,\ as registered
in the Directory in the mhs\(hypreferred\(hydelivery\(hymethod attribute),
the originator's
\fBrequested\(hydelivery\(hymethod\fR takes precedence. If the originator's
conversion
requirements (see \(sc\(sc\ 8.2.1.1.1.9 to\ 8.2.1.1.1.11), a non\(hydelivery
report shall be returned to the originator of the message.
.RT
.sp 1P
.LP
8.2.1.1.1.15\ \
\fIPhysical\(hyforwarding\(hyprohibited\fR
.sp 9p
.RT
.PP
This argument indicates whether physical\(hyforwarding of the message is
prohibited. It may be generated by the originator of the message if the
\fBrequested\(hydelivery\(hymethod\fR argument specifies that physical\(hydelivery
is
required to the recipient, or if the originator of the message supplied a
\fBpostal\(hyOR\(hyaddress\fR for the recipient. A different value of this
argument may be specified for each recipient of the message.
.PP
This argument may have one of the following values:
\fBphysical\(hyforwarding\(hyallowed\fR , or \fBphysical\(hyforwarding\(hyprohibited\fR
.
.PP
In the absence of this argument, the default
\fBphysical\(hyforwarding\(hyallowed\fR shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.16\ \
\fIPhysical\(hyforwarding\(hyaddress\(hyrequest\fR
.sp 9p
.RT
.PP
This argument indicates whether the physical\(hyforwarding\(hyaddress of
the recipient is to be returned in this report. It may be generated by
the
originator of the message if the \fBrequested\(hydelivery\(hymethod\fR
argument specifies that physical\(hydelivery is required to the recipient,
or if the originator of
the message supplied a \fBpostal\(hyOR\(hyaddress\fR for the recipient.
A different value of this argument may be specified for each recipient
of the message.
.PP
This argument may have one of the following values:
\fBphysical\(hyforwarding\(hyaddress\(hyrequested\fR or
\fBphysical\(hyforwarding\(hyaddress\(hynot\(hyrequested\fR .
.PP
In the absence of this argument, the default
\fBphysical\(hyforwarding\(hyaddress\(hynot\(hyrequested\fR shall be assumed.
.PP
A physical\(hyforwarding\(hyaddress may be requested when
physical\(hyforwarding is prohibited or allowed
(see\ \(sc\ 8.2.1.1.1.15).
.bp
.RT
.sp 1P
.LP
8.2.1.1.1.17\ \
\fIPhysical\(hydelivery\(hymodes\fR
.sp 9p
.RT
.PP
This argument indicates the mode of physical\(hydelivery to the
recipient to be used. It may be generated by the originator of the message
if the \fBrequested\(hydelivery\(hymethod\fR argument specifies that physical\(hydelivery
is
required to the recipient, or if the originator of the message supplied a
\fBpostal\(hyOR\(hyaddress\fR for the recipient. A different value of this
argument may be specified for each recipient of the message.
.PP
This argument may have one of the following values: \fBordinary\(hymail\fR
, \fBspecial\(hydelivery\fR , \fBexpress\(hymail\fR , \fBcounter\(hycollection\fR
,
\fBcounter\(hycollection\(hywith\(hytelephone\(hyadvice\fR ,
\fBcounter\(hycollection\(hywith\(hytelex\(hyadvice\fR ,
\fBcounter\(hycollection\(hywith\(hyteletex\(hyadvice\fR , or \fBbureau\(hyfax\(hydelivery\fR
.
.PP
Note that \fBbureau\(hyfax\(hydelivery\fR comprises all A to H modes of
delivery defined in Recommendation\ F.170, i.e.,\ A\ \(em\ regular delivery,
B\ \(em\ special
delivery, C\ \(em\ express mail, D\ \(em\ counter collection, E\ \(em\
counter collection with telephone advice, F\ \(em\ telefax, G\ \(em\ counter
collection with telex advice, and
H\ \(em\ counter collection with teletex advice.
.PP
In the absence of this argument, the default \fBordinary\(hymail\fR shall
be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.18\ \
\fIRegistered\(hymail\(hytype\fR
.sp 9p
.RT
.PP
This argument indicates the type of registered mail service to be used
physically deliver the message to the recipient. It may be generated by
the originator of the message if the \fBrequested\(hydelivery\(hymethod\fR
argument
specifies that physical delivery is required to the recipient, or if the
originator of the message supplied a \fBpostal\(hyOR\(hyaddress\fR for
the recipient. A different value of this argument may be specified for
each recipient of the
message.
.PP
This argument may have one of the following values:
\fBnon\(hyregistered\(hymail\fR , \fBregistered\(hymail\fR , or
\fBregistered\(hymail\(hyto\(hyaddressee\(hyin\(hyperson\fR .
.PP
In the absence of this argument, the default \fBordinary\(hymail\fR shall
be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.19\ \
\fIRecipient\(hynumber\(hyfor\(hyadvice\fR
.sp 9p
.RT
.PP
This argument contains the telephone, telex or teletex number of
the recipient, to be used in conjunction with the
\fBcounter\(hycollection\(hywith\(hyadvice\fR and \fBbureau\(hyfax\(hydelivery
physical\(hydelivery\(hymodes\fR . It may be generated by the originator
of the message if the \fBrequested\(hydelivery\(hymethod\fR argument specifies
that physical\(hydelivery is required to the recipient, or if the originator
of the message supplied a
\fBpostal\(hyOR\(hyaddress\fR for the recipient, and the \fBphysical\(hydelivery\(hymodes\fR
argument specifies a \fBcounter\(hycollection\(hywith\(hyadvice\fR or \fBbureau\(hyfax\(hydelivery
physical\(hydelivery\(hymode\fR . A different value of this argument may
be specified
for each recipient of the message.
.RT
.sp 1P
.LP
8.2.1.1.1.20\ \
\fIPhysical\(hyrendition\(hyattributes\fR
.sp 9p
.RT
.PP
This argument indicates the \fBphysical\(hyrendition\(hyattributes\fR of
the message. It may be generated by the originator of the message if the
\fBrequested\(hydelivery\(hymethod\fR argument specifies that physical\(hydelivery
is
required to the recipient, or if the originator of the message supplied a
\fBpostal\(hyOR\(hyaddress\fR for the recipient. A different value of this
argument may be specified for each recipient of the message.
.PP
This argument may have one of the following values: \fBbasic\fR . Future
versions of this Recommendation may define other values of this argument.
Other values of this argument may be used by bilateral agreement between
MDs.
.PP
In the absence of this argument, the default \fBbasic\fR shall be
assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.21\ \
\fIOriginator\(hyreturn\(hyaddress\fR
.sp 9p
.RT
.PP
This argument contains the \fBpostal\(hyOR\(hyaddress\fR of the originator
of the message. It shall be generated by the originator of the message
if the
\fBrequested\(hydelivery\(hymethod\fR argument specifies that physical\(hydelivery
is
required to one or more recipients of the message, or if the originator
of the message supplied one or more \fBpostal\(hyOR\(hyaddress\fR for the
recipients. It may
also be generated by the originator of the message if a recipient\ DL contains,
or is likely to contain, one or more members for whom physical\(hydelivery
is
required.
.PP
The \fBoriginator\(hyreturn\(hyaddress\fR shall contain the \fBpostal\(hyOR\(hyaddress\fR
of an individual originator (\fBOR\(hyaddress\fR ), i.e.,\ shall not contain
the
\fBdirectory\(hyname\fR of an individual originator nor the \fBdirectory\(hyname\fR
of a
DL.
.bp
.RT
.sp 1P
.LP
8.2.1.1.1.22\ \
\fIOriginator\(hyreport\(hyrequest\fR
.sp 9p
.RT
.PP
This argument indicates the kind of report requested by the
originator of the message. It shall be generated by the originator of the
message. A different value of this argument may be specified for each recipient
of the message.
.PP
This argument may have one of the following values:
.RT
.LP
\(em
\fBno\(hyreport\fR : the originator of the message requested the
suppression of non\(hydelivery\(hyreports;
.LP
\(em
\fBnon\(hydelivery\(hyreport\fR : a report is returned only in case of
non\(hydelivery;
.LP
\(em
\fBreport\fR : a report is returned in case of delivery or
non\(hydelivery.
.PP
Note that the value of this argument may be changed at a DL
expansion\(hypoint in line with the reporting\(hypolicy of the DL. Such
a change may affect the number and type of reports the originator of the
message may receive about delivery to a DL.
.sp 1P
.LP
8.2.1.1.1.23\ \
\fIContent\(hyreturn\(hyrequest\fR
.sp 9p
.RT
.PP
This argument indicates whether the message \fBcontent\fR is to be
returned with any non\(hydelivery\(hyreport(s). It may be generated by
the originator of the message.
.PP
This argument may have one of the following values:
\fBcontent\(hyreturn\(hyrequested\fR or \fBcontent\(hyreturn\(hynot\(hyrequested\fR
.
.PP
In the absence of this argument, the default
\fBcontent\(hyreturn\(hynot\(hyrequested\fR shall be assumed.
.PP
Note that the suppression of non\(hydelivery\(hyreports by the
originator of the message (see \(sc\ 8.2.1.1.1.22) takes precedence over
a request for the return of the \fBcontent\fR .
.PP
Note that in the case of non\(hydelivery\(hyreports delivered to the
owner of a DL (see \(sc\ 8.3.1.2.1.4), the message \fBcontent\fR shall not be
present.
.RT
.sp 1P
.LP
8.2.1.1.1.24\ \
\fIPhysical\(hydelivery\(hyreport\(hyrequest\fR
.sp 9p
.RT
.PP
This argument indicates the type of physical\(hydelivery\(hyreport
requested by the originator of the message. It may be generated by the
originator of the message if the \fBrequested\(hydelivery\(hymethod\fR
argument specifies that physical\(hydelivery is required to the recipient
or if the originator of the message supplied a \fBpostal\(hyOR\(hyaddress\fR
for the recipient. A different value of this argument may be specified
for each recipient of the message.
.PP
This argument may have one of the following values:
\fBreturn\(hyof\(hyundeliverable\(hymail\(hyby\(hyPDS, return\(hyof\(hynotification\(hyby
PDS,\fR
\fBreturn\(hyof\(hynotification\(hyby\(hyMHS\fR , or \fBreturn\(hyof\(hynotification\(hyby\(hyMHS\(hyand\(hyPDS\fR
.
.PP
In the absence of this argument, the default
\fBreturn\(hyof\(hyundeliverable\(hymail\(hyby\(hyPDS\fR shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.25\ \
\fIOriginator\(hycertificate\fR
.sp 9p
.RT
.PP
This argument contains the \fBcertificate\fR of the originator of the message.
It shall be generated by a trusted source (e.g.\ a
certification\(hyauthority), and may be supplied by the originator of the
message.
.PP
The \fBoriginator\(hycertificate\fR may be used to convey a verified copy
of the public\(hyasymmetric\(hyencryption\(hykey (\fBsubject\(hypublic\(hykey\fR
) of the originator of the message.
.PP
The originator's public\(hyasymmetric\(hyencryption\(hykey may be used
by the recipient(s) of the message to validate the \fBmessage\(hytoken\fR
, if an
\fBasymmetric\(hytoken\fR , if an \fBasymmetric\(hytoken\fR is used.
.PP
The originator's public\(hyasymmetric\(hyencryption\(hykey may also be
used by the recipient(s) of the message, and any MTA through which the
message is
transferred, to validate the \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR
.
.RT
.sp 1P
.LP
8.2.1.1.1.26\ \
\fIMessage\(hytoken\fR
.sp 9p
.RT
.PP
This argument contains the \fBtoken\fR associated with the message. It
may be generated by the originator of the message. A different value of
this
argument may be specified for each recipient of the message.
.PP
If the \fBmessage\(hytoken\fR is an \fBasymmetric\(hytoken\fR , the \fBsigned\(hydata\fR
may comprise:
.RT
.LP
\(em
any of the following arguments: the
\fBcontent\(hyconfidentiality\(hyalgorithm\(hyidentifier\fR , the \fBcontent\(hyintegrity\(hycheck\fR
, the \fBmessage\(hysecurity\(hylabel\fR , and the \fBproof\(hyof\(hydelivery\(hyrequest\fR
; and
.LP
\(em
a \fBmessage\(hysequence\(hynumber\fR , that identifies the position
of the message in a sequence of messages from the originator to the recipient
to which the \fBmessage\(hytoken\fR relates (to provide the Message Sequence
Integrity
element\(hyof\(hyservice, as defined in Recommendaton\ X.400).
.bp
.PP
If the \fBmessage\(hytoken\fR is an \fBasymmetric\(hytoken\fR , the
\fBencrypted\(hydata\fR may comprise:
.LP
\(em
a \fBcontent\(hyconfidentiality\(hykey\fR : a symmetric\(hyencryption\(hykey
used with the \fBcontent\(hyconfidentiality\(hy\fR
\fBalgorithm\(hyidentifier\fR by the
originator
of the message to encrypt the message \fBcontent\fR , and by the recipient to
decrypt the message \fBcontent\fR ; and/or
.LP
\(em
the \fBcontent\(hyintegrity\(hycheck\fR : may be included in the
\fBencrypted\(hydata\fR , rather than the \fBsigned\(hydata\fR , if confidentiality
of the
\fBcontent\(hyintegrity\(hycheck\fR is required, and/or if the \fBmessage\(hysecurity\(hylabel\fR
is included in the \fBencrypted\(hydata\fR (for confidentiality of the
\fBmessage\(hysecurity\(hylabel\fR ) and the association between\fR \fBcontent\(hyintegrity\(hycheck\fR
and the \fBmessage\(hysecurity\(hylabel\fR is to be
maintained;
.LP
\(em
the \fBmessage\(hysecurity\(hylabel\fR : may be included in the
\fBencrypted\(hydata\fR , rather than the \fBsigned\(hydata\fR , if confidentiality
of the
\fBmessage\(hysecurity\(hylabel\fR is required;
.LP
\(em
a \fBcontent\(hyintegrity\(hykey\fR : a symmetric\(hyencryption\(hykey used
with the \fBcontent\(hyintegrity\(hyalgorithm\(hyidentifier\fR by the originator
of the
message to compute the \fBcontent\(hyintegrity\(hycheck\fR , and by the
recipient to
validate the \fBcontent\(hyintegrity\(hycheck\fR ;
.LP
\(em
a \fBmessage\(hysequence\(hynumber\fR : as defined for the \fBsigned\(hydata\fR
above, but may be included in the \fBencrypted\(hydata\fR instead if confidentiality
of the sequence is required.
.PP
If the \fBmessage\(hytoken\fR is an \fBasymmetric\(hytoken\fR and the
\fBsigned\(hydata\fR of the \fBmessage\(hytoken\fR includes the \fBcontent\(hyintegrity\(hycheck\fR
,
the \fBmessage\(hytoken\fR provides for non\(hyrepudiation\(hyof\(hyorigin
of message \fBcontent\fR (the
non\(hyrepudiation of origin element\(hyof\(hyservice, as defined in
Recommendation\ X.400). If the \fBsigned\(hydata\fR of the \fBmessage\(hytoken\fR
includes
both the \fBcontent\(hyintegrity\(hycheck\fR and the \fBmessage\(hysecurity\(hylabel\fR
, the
\fBmessage\(hytoken\fR provides proof of association between the
\fBmessage\(hysecurity\(hylabel\fR and the message \fBcontent\fR .
.sp 1P
.LP
8.2.1.1.1.27\ \
\fIContent\(hyconfidentiality\(hyalgorithm\(hyidentifier\fR
.sp 9p
.RT
.PP
This argument contains an \fBalgorithm\(hyidentifier\fR , which identifies
the algorithm used by the originator of the message to encrypt the message
\fBcontent\fR (to provide the content confidentiality element\(hyof\(hyservice
as defined in Recommendation\ X.400). It may be generated by the originator
of the
message.
.PP
The algorithm may be used by the recipient(s) of the message to
decrypt the message \fBcontent\fR .
.PP
The content\(hyconfidentiality altorithm may be either a symmetric\(hy
or an asymmetric\(hyencryption\(hyalgorithm.
.PP
If a symmetric\(hyencryption\(hyalgorithm is used, the
\fBcontent\(hyconfidentiality\(hykey\fR used by the originator to encrypt
the message
\fBcontent\fR , and which the recipient may use to decrypt the message
\fBcontent\fR ,
may be derived from the \fBmessage\(hytoken\fR sent with the message. Alternatively,
\fBcontent\(hyconfidentiality\(hykey\fR may be distributed by some other
means.
.PP
If an asymmetric\(hyencryption\(hyalgorithm is used, the
intended\(hyrecipient's public\(hyasymmetric\(hyencryption\(hykey may be
used by the
originator of the message to encrypt the message \fBcontent\fR . The recipient
may use the recipient's secret\(hyasymmetric\(hyencryption\(hykey to decrypt
the message
\fBcontent\fR . Note that if an asymmetric\(hyencryption\(hyalgorithm is
used, the message can only be addressed to a single recipient, or to a
set of recipients which
share the same asymmetric\(hyencryption\(hykey pair.
.RT
.sp 1P
.LP
8.2.1.1.1.28\ \
\fIContent\(hyintegrity\(hycheck\fR
.sp 9p
.RT
.PP
This argument provides the recipient(s) of the message with a means of
validating that the message \fBcontent\fR has not been modified (to provide
the content integrity element\(hyof\(hyservice as defined in Recommendation\
X.400). It
may be generated by the originator of the message. A different value of the
argument may be specified for each recipient of the message.
.PP
The \fBcontent\(hyintegrity\(hycheck\fR enables content\(hyintegrity to be
validated on a per\(hyrecipient basis using either a symmetric\(hy or an
asymmetric\(hyencryption\(hyalgorithm. Note that the
\fBmessage\(hyorigin\(hyauthentication\(hycheck\fR provides a means of
validating
content\(hyintegrity on a per\(hymessage basis using an
asymmetric\(hyencryption\(hyalgorithm.
.PP
The \fBcontent\(hyintegrity\(hycheck\fR may be included in the \fBsigned\(hydata\fR
or the \fBencrypted\(hydata\fR of the \fBmessage\(hytoken\fR to provide
for
non\(hyrepudiation\(hyof\(hyorigin of the message \fBcontent\fR , and proof
of association
between the \fBmessage\(hy\fR
\fBsecurity\(hylabel\fR and the message \fBcontent\fR .
.PP
The \fBcontent\(hyintegrity\(hycheck\fR is computed using the algorithm
identified by the \fBcontent\(hyintegrity\(hyalgorithm\(hyidentifier\fR (an
\fBalgorithm\(hyidentifier\fR ).
.bp
.PP
The \fBcontent\(hyintegrity\(hycheck\fR contains the
\fBcontent\(hyintegrity\(hyalgorithm\(hyidentifier\fR , and an encrypted
function (e.g.,\ a
compressed or hashed version) of the \fBcontent\(hyintegrity\(hyalgorithm\(hyidentifier\fR
and the message \fBcontent\fR . Note that the \fBcontent\(hyintegrity\(hycheck\fR
is computed using the clear (i.e.\ unencrypted) message \fBcontent\fR .
.PP
The content\(hyintegrity\(hyalgorithm may be either a symmetric\(hy or an
asymmetric\(hyencryption\(hyalgorithm. Note that the use of a symmetric\(hyencryption
algorithm may permit simultaneous compression and encryption of the message
\fBcontent\fR .
.PP
If a symmetric\(hyencryption\(hyalgorithm is used, the
\fBcontent\(hyintegrity\(hykey\fR used to compute the \fBcontent\(hyintegrity\(hycheck\fR
, and
which the recipient may use to validate the \fBcontent\(hyintegrity\(hycheck\fR
, may be derived from the \fBmessage\(hytoken\fR sent with the message.
Alternatively, the
\fBcontent\(hyintegrity\(hykey\fR may be distributed by some other means.
.PP
If an asymmetric\(hyencryption\(hyalgorithm is used, the originator's
secret\(hyasymmetric\(hyencryption\(hykey may be used by the originator
of the message to compute the \fBcontent\(hyintegrity\(hycheck\fR . The
recipient may use the
originator's public\(hyasymmetric\(hyencryption\(hykey (\fBsubject\(hypublic\(hykey\fR
) derived
from the \fBoriginator\(hycertificate\fR to validate the
\fBcontent\(hyintegrity\(hycheck\fR .
.RT
.sp 1P
.LP
8.2.1.1.1.29\ \
\fIMessage\(hyorigin\(hyauthentication\(hycheck\fR
.sp 9p
.RT
.PP
This argument provides the recipient(s) of the message, and any MTA through
which the message is transferred, with a means of authenticating the
origin of the message (to provide the Message Origin Authentication
element\(hyof\(hyservice as defined in Recommendation\ X.400). It may be
generated by the originator of the message.
.PP
The \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR provides proof of the
origin of the message (message origin authentication), assurance that the
message \fBcontent\fR has not been modified (the content integrity
element\(hyof\(hyservice as defined in Recommendation\ X.400), and proof of
association between the \fBmessage\(hysecurity\(hylabel\fR and the message.
.PP
The \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR is computed using the
algorithm (asymmetric\(hyencryption\(hyalgorithm and hash\(hyfunction)
identified by
the \fBmessage\(hyorigin\(hyauthentication\(hyalgorithm\(hyidentifier\fR (an
\fBalgorithm\(hyidentifier\fR ).
.PP
The \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR contains the
\fBmessage\(hyorigin\(hyauthentication\(hyalgorithm\(hyidentifier\fR ,
and an asymmetrically
encrypted, hashed version of the
\fBmessage\(hyorigin\(hyauthentication\(hyalgorithm\(hyidentifier\fR ,
the message \fBcontent\fR ,
the \fBcontent\(hyidentifier\fR and the \fBmessage\(hysecurity\(hylabel\fR
. Optional components are included in the \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR
if they are present in the message.
.PP
If content\(hyconfidentiality (see \(sc 8.2.1.1.1.27) is also used, the
\fBmessage\(hyorigin\(hyauthentication\(hycheck\fR is computed using the
encrypted version of the message \fBcontent\fR (to allow the \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR
to be validated by other than the intended\(hyrecipient (e.g.\ by an MTA)
without compromising the confidentiality of the message \fBcontent\fR ).
Note that if the
clear (i.e.\ unencrypted) version of the message \fBcontent\fR is used
to compute
the \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR , the \fB
message\(hyorigin\(hyauthentication\(hycheck\fR provides for both message\(hyorigin
authentication and non\(hyrepudiation of origin of the message \fBcontent\fR (a
signature), as defined in Recommendation\ X.400. If, however, the encrypted
version of the message \fBcontent\fR is used, the \fB
message\(hyorigin\(hyauthentication\(hycheck\fR provides for message\(hyorigin
authentication, but not for non\(hyrepudiation of origin of the message
\fBcontent\fR .
.PP
\fR
.PP
The \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR may be computed by the
originator of the message using the originator's
secret\(hyasymmetric\(hyencryption\(hykey. The \fBmessage\(hyorigin\(hyauthentication\(hycheck\fR
may be validated by the recipient(s) of the message, and any MTA through
which the message is transferred, using the public\(hyasymmetric\(hyencryption\(hykey
\fB
(\fBsubject\(hypublic\(hykey\fR ) of the originator of the message derived
from the
\fBoriginator\(hycertificate\fR .
.PP
Future version of this Recommendation may define other forms of
\fBmessage\(hyorigin\(hyauthentication\(hycheck\fR (e.g.,\ based on
symmetric\(hyencryption\(hytechniques) which may be used by MTAs through
which the
message is transferred to authenticate the origin of the message.
.RT
.sp 1P
.LP
8.2.1.1.1.30\ \
\fIMessage\(hysecurity label\fR
.sp 9p
.RT
.PP
This argument associates a \fBsecurity\(hylabel\fR with the message (or
probe). It may be generated by the originator of the message (or probe), in
line with the security\(hypolicy in force.
.PP
The \fBmessage\(hysecurity label\fR of a report shall be the same as the\fR
\fBmessage\(hysecurity label\fR of the subject\(hymessage (or subject\(hyprobe).
.bp
.PP
If \fBsecurity\(hylabels\fR are assigned to MTS\(hyusers, MTAs and other
objects
in the MHS, the handling by those objects of messages, probes and reports
bearing \fBmessage\(hysecurity\(hylabels\fR may be determined by the security\(hypolicy
in force. If \fBsecurity\(hylabels\fR are not assigned to MTS\(hyusers,
MTAs and other
objects in the MHS, the handling by those objects of messages, probes and
reports bearing \fBmessage\(hysecurity\(hylabels\fR may be discretionary.
.PP
If \fBsecurity\(hycontexts\fR are established between the originator and
an MTA (the originating\(hyMTA) of the MTS (see \(sc\(sc\ 8.1.1.1.1.3 and
8.2.1.4.1.5), the \fBmessage\(hysecurity\(hylabel\fR that the originator
may assign to a message (or probe) may be determined by the \fBsecurity\(hycontext\fR
(submission\(hysecurity\(hycontext), in line with the security\(hypolicy
in force. If \fBsecurity\(hycontexts\fR are not
established between the originator and the originating\(hyMTA, the assignment
of a \fBmessage\(hysecurity\(hylabel\fR to a message (or probe) may be
at the discretion of
the originator.
.PP
If \fBsecurity\(hycontexts\fR are established between two MTAs (see \(sc
12.1.1.1.1.3), the transfer of messages, probes or reports between the
MTAs may be determined by the \fBmessage\(hysecurity\(hylabels\fR of the
messages, probes or
reports, and the \fBsecurity\(hycontext\fR , in line with the security\(hypolicy
in force. If \fBsecurity\(hycontexts\fR are not established between the
MTAs, the transfer of
messages, probes and reports may be at the discretion of the sender.
.PP
If \fBsecurity\(hycontexts\fR are established between an MTS\(hyuser and
an MTA (the delivering\(hyMTA) of the MTS (see \(sc\(sc\ 8.1.1.1.1.3 and
8.3.1.3.1.7), the
delivery of messages and reports may be determined by the
\fBmessage\(hysecurity\(hylabels\fR of the messages and reports, and the
\fBsecurity\(hycontext\fR (delivery\(hysecurity\(hycontext), in line with the
security\(hypolicy in force. If the \fBmessage\(hysecurity\(hylabel\fR
of a message or
report is allowed by the registered \fBuser\(hysecurity\(hylabels\fR of
the recipient,
but disallowed by the recipient's current \fBsecurity\(hycontext\fR (delivery\(hysecurity\(hycontext),
then the delivering\(hyMTA may hold\(hyfor\(hydelivery. If \fBsecurity\(hycontexts\fR
are not established between the MTS\(hyuser and the
delivering\(hyMTA, the delivery of messages and reports may be at the discretion
of the delivering\(hyMTA.
.RT
.sp 1P
.LP
8.2.1.1.1.31\ \
\fIProof\(hyof\(hysubmission\(hyrequest\fR
.sp 9p
.RT
.PP
This argument indicates whether or not the originator of the
message requires \fBproof\(hyof\(hysubmission\fR (to provide the proof
of submission
element\(hyof\(hyservice) as defined in Recommendation\ X.400) of the message
to the MTS. It may be generated by the originator of the message.
.PP
This argument may have one of the following values:
\fBproof\(hyof\(hysubmission\(hyrequested\fR or \fBproof\(hyof\(hysubmission\(hynot\(hyrequested\fR
.
.PP
\fR
In the absence of this argument, the default
\fBproof\(hyof\(hysubmission\(hynot\(hyrequested\fR shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.32\ \
\fIProof\(hyof\(hydelivery\(hyrequest\fR
.sp 9p
.RT
.PP
This argument indicates whether or not the originator of the
message requires \fBproof\(hyof\(hydelivery\fR (to provide the proof of
delivery
element\(hyof\(hyservice as defined in Recommendation\ X.400) of the message
to the
recipient. It may be generated by the originator of the message. A different
value of this argument may be specified for each recipient of the message.
.PP
This argument may have one of the following values:
\fBproof\(hyof\(hydelivery\(hyrequested\fR or \fBproof\(hyof\(hydelivery\(hynot\(hyrequested\fR
.
.PP
\fR
In the absence of this argument, the default
\fBproof\(hyof\(hydelivery\(hynot\(hyrequested\fR shall be assumed.
.RT
.sp 1P
.LP
8.2.1.1.1.33\ \
\fIOriginal\(hyencoded\(hyinformation\(hytypes\fR
.sp 9p
.RT
.PP
This argument identifies the original \fBencoded\(hyinformation\(hytypes\fR
of the message \fBcontent\fR . It may be generated by the originator of
the
message.
.PP
The absence of this argument indicates that the
\fBoriginal\(hyencoded\(hyinformation\(hytypes\fR of the message \fBcontent\fR
are
unspecified.
.RT
.sp 1P
.LP
8.2.1.1.1.34\ \
\fIContent\(hytype\fR
.sp 9p
.RT
.PP
This argument identifies the type of the content of the message. It shall
be generated by the originator of the message. The \fBcontent\(hytype\fR
shall be either built\(hyin or extended.
.PP
A built\(hyin \fBcontent\(hytype\fR may have one of the following
values:
.RT
.LP
\(em
\fBunidentified:\fR denotes a \fBcontent\(hytype\fR unidentified and
unconstrained; the of this \fBunidentified content\(hy\fR
\fBtype\fR is by bilateral
agreement between MTS\(hyusers;
.LP
\(em
\fBexternal:\fR denotes a \fBcontent\(hytype\fR which is reserved for
use when interworking between 1988\ systems and 1984\ systems (see
Recommendation\ X.419);
.LP
\(em
\fBinterpersonal\(hymessaging\(hy1984\fR : identifies the
\fBinterpersonal\(hymessaging\(hy1984 content\(hytype\fR defined in Recommendation\
X.420;
.bp
.LP
\(em
\fBinterpersonal\(hymessaging\(hy1988\fR : identifies the
\fBinterpersonal\(hymessaging\(hy1988 content\(hytype\fR defined in Recommendation\
X.420;
.LP
\(em
one specific value of an extended \fBcontent\(hytype\fR which has
been defined by this Recommendation is \fBinner\(hyenvelope\fR : an extended
\fBcontent\(hytype\fR that is itself a message (envelope and content),
for forwarding by the recipient named on the outer\(hyenvelope to those
named on the
inner\(hyenvelope. The type of the \fBcontent\fR OCTET STRING in an \fBMTS\(hyAPDU\fR
,
encoded using the Basic Encoding Rules of ASN.1. [Note that the inner\(hyenvelope
and using the security arguments (see \(sc\(sc\ 8.2.1.1.1.25 to 8.2.1.1.1.32).]
.PP
Other standardized \fBextended\fR \fBcontent\(hytypes\fR may be defined by
future versions of this Recommendation. Other values of this argument may be
used by bilateral agreement between MTS\(hyusers.
.sp 1P
.LP
8.2.1.1.1.35\ \
\fIContent\(hyidentifier\fR
.sp 9p
.RT
.PP
This argument contains an identifier for the \fBcontent\fR of the
message. It may be generated by the originator of the message.
.PP
The \fBcontent\(hyidentifier\fR may be delivered to the recipient(s) of
the message, and is returned to the originator with any report(s). This
argument is not altered by the MTS.
.RT
.sp 1P
.LP
8.2.1.1.1.36\ \
\fIContent\(hycorrelator\fR
.sp 9p
.RT
.PP
This argument contains information to enable correlation of the
\fBcontent\fR of the message by the originator of the message. It may be
generated by the originator of the message.
.PP
The \fBcontent\(hycorrelator\fR is not delivered to the recipient(s) of
the message, but is returned to the originator with any report(s). This
argument
is not altered by the MTS.
.RT
.sp 1P
.LP
8.2.1.1.1.37\ \
\fIContent\fR
.sp 9p
.RT
.PP
This argument contains the information the message is intended to convey
to the recipient(s). It shall be generated by the originator of the
message.
.PP
Except when conversion is performed, the \fBcontent\fR of the message is
not modified by the MTS, but rather is passed transparently through it.
.PP
The \fBcontent\fR may be encrypted to ensure its confidentiality (see
\(sc\ 8.2.1.1.1.27).
.PP
The \fBcontent\fR may be an \fBexternal\(hycontent\fR . The \fBcontent\fR is an
\fBexternal\(hycontent\fR when the \fBcontent\(hytype\fR argument has the
value \fBexternal\fR . When the \fBcontent\fR is an \fBexternal\(hycontent\fR
, the \fBexternal\(hycontent\(hytype\fR is
specified by the object identifier of the \fBexternal\(hycontent\fR . An
\fBexternal\(hycontent\fR may be used to convey an \fBinner\(hyenvelope\fR (see
\(sc\ 8.2.1.1.1.34), or for interworking between 1988\ systems and 1984\
systems
(see Recommendation\ X.419).
.RT
.LP
\fR \fR \fR
.sp 1P
.LP
8.2.1.1.2\ \ \fIResults\fR
.sp 9p
.RT
.PP
Table 5/X.411 lists the results of the message\(hysubmission
abstract\(hyoperation, and for each result qualifies its presence and identifies
the clause in which the result is defined.
.RT
.ce
\fBH.T. [T5.411]\fR
.ce
TABLE\ 5/X.411
.ce
\fBMessage\(hysubmission results\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(36p) .
Result Presence Clause
_
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Message\(hysubmission\(hyidentifier
T} M 8.2.1.1.2.1\
.T&
lw(90p) | cw(30p) | cw(36p) .
Message\(hysubmission\(hytime M 8.2.1.1.2.2\
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Originating\(hyMTA\(hycertificate
T} O 8.2.1.1.2.3\
.T&
lw(90p) | cw(30p) | cw(36p) .
Proof\(hyof\(hysubmission C 8.2.1.1.2.4\
.T&
lw(90p) | cw(30p) | cw(36p) .
Content\(hyidentifier C 8.2.1.1.1.35
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 5/X.411 [T5.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
8.2.1.1.2.1\ \
\fIMessage\(hysubmission\(hyidentifier\fR
.sp 9p
.RT
.PP
This result contains an \fBMTS\(hyidentifier\fR that uniquely and
unambiguously identifies the message\(hysubmission. It shall be generated
by the MTS.
.PP
The MTS provides the \fBmessage\(hysubmission\(hyidentifier\fR when notifying
the MTS\(hyuser, via the report\(hydelivery abstract\(hyoperation, of the
delivery or
non\(hydelivery of the message.
.PP
The MTS\(hyuser provides the \fBmessage\(hysubmission\(hyidentifier\fR when
cancelling, via the cancel\(hydeferred\(hydelivery abstract\(hyoperation,
a message
whose delivery it deferred.
.RT
.sp 1P
.LP
8.2.1.1.2.2\ \
\fIMessage\(hysubmission\(hytime\fR
.sp 9p
.RT
.PP
This result indicates the \fBtime\fR at which the MTS accepts
responsibility for the message. It shall be generated by the MTS.
.RT
.sp 1P
.LP
8.2.1.1.2.3\ \
\fIOriginating\(hyMTA\(hycertificate\fR
.sp 9p
.RT
.PP
This result contains the \fBcertificate\fR of the MTA to which the
message has been submitted (the originating\(hyMTA). It shall be generated by a
trusted source (e.g.\ a certification\(hyauthority), and may be supplied by the
originating\(hyMTA, if the originator of the message requested
\fBproof\(hyof\(hysubmission\fR (see \(sc\ 8.2.1.1.1.31) and an
asymmetric\(hyencryption\(hyalgorithm is used to compute the \fBproof\(hyof\(hysubmission\fR
.
.PP
The \fBoriginating\(hyMTA\(hycertificate\fR may be used to convey to the
originator of the message a verified copy of the
public\(hyasymmetric\(hyencryption\(hykey (\fBsubject\(hypublic\(hykey\fR
) of the originating
MTA.
.PP
The originating\(hyMTA's public\(hyasymmetric\(hyencryption\(hykey may
be used by the originator of the message to validate the \fBproof\(hyof\(hysubmission\fR
.
.RT
.sp 1P
.LP
8.2.1.1.2.4\ \
\fIProof\(hyof\(hysubmission\fR
.sp 9p
.RT
.PP
This result provides the originator of the message with proof of
submission of the message to the MTS (to provide the proof of submission
element\(hyof\(hyservice as defined in Recommendation\ X.400). Depending on the
encryption\(hyalgorithm used and the security policy in force, this argument
may also provide the non\(hyrepudiation of submission element\(hyof\(hyservice
(as defined in Recommendation\ X.400). It shall be generated by the originating\(hyMTA
of the MTS, if the originator of the message requested \fBproof\(hyof\(hysubmission\fR
(see
\(sc\ 8.2.1.1.1.31).
.PP
The \fBproof\(hyof\(hysubmission\fR is computed using the algorithm identified
by the \fBproof\(hyof\(hysubmission\(hyalgorithm\(hyidentifier\fR (an
\fBalgorithm\(hyidentifier\fR .)
.PP
The \fBproof\(hyof\(hysubmission\fR contains the
\fBproof\(hyof\(hysubmission\(hyalgorithm\(hyidentifier\fR , and an encrypted
function (e.g.,\ a compressed or hashed version) of the
\fBproof\(hyof\(hysubmission\(hyalgorithm\(hyidentifier\fR , the arguments
of the submitted
message (see \(sc\ 8.2.1.1.1), and the \fBmessage\(hysubmission\(hyidentifier\fR
and\fR
\fBmessage\(hysubmission\(hytime\fR . Optional components are included
in the\fB \fR \fB
\fBproof\(hyof\(hysubmission\fR if they are present in the message.
.PP
Note that receipt of this result provides the originator of the
message with proof of submission of the message. Non\(hyreceipt of this result
provides neither proof of submission nor proof of non\(hysubmission (unless a
secure link and trusted functionality are employed).
.PP
If an asymmetric\(hyencryption\(hyalgorithm is used, the
\fBproof\(hyof\(hysubmission\fR may be computed by the originating\(hyMTA
using the
originating\(hyMTA's secret\(hyasymmetric\(hyencryption\(hykey. The originator
of the
message may validate the \fBproof\(hyof\(hysubmission\fR using the originating\(hyMTA's
public\(hyasymmetric\(hyencryption\(hykey (\fBsubject\(hypublic\(hykey\fR
) derived from the
\fBoriginating\(hyMTA\(hycertificate\fR . An asymmetric \fBproof\(hyof\(hysubmission\fR
may also
provide for non\(hyrepudiation of submission.
.PP
If a symmetric\(hyencryption\(hyalgorithm is used, the
summetric\(hyencryption\(hykey that the originating\(hyMTA used to compute the
\fBproof\(hyof\(hysubmission\fR , and which the originator may use to validate
the
\fBproof\(hyof\(hysubmission\fR , may be derived from the \fBbind\(hytokens\fR
(see
\(sc\(sc\ 8.1.1.1.1.3
and 8.1.1.1.2.2) exchanged when the association was initiated. Alternatively,
the symmetric\(hyencryption\(hykey used for \fBproof\(hyof\(hysubmission\fR
may be exchanged by some other means. Note that if a symmetric\(hyencryption\(hyalgorithm
is used then
the \fBproof\(hyof\(hysubmission\fR can only support non\(hyrepudiation
of submission if the security\(hypolicy in force provides for the involvement
of a third party acting as a notary.
.RT
.sp 1P
.LP
8.2.1.1.3\ \
\fIAbstract\(hyerrors\fR
.sp 9p
.RT
.PP
Table 6/X.411 lists the abstract\(hyerrors\fR that may disrupt the
message\(hysubmission abstract\(hyoperation, and for each abstract\(hyerror
identifies the clause in which the abstract\(hyerror is defined.
.bp
.RT
.ce
\fBH.T. [T6.411]\fR
.ce
TABLE\ 6/X.411
.ce
\fBMessage\(hysubmission abstract\(hyerrors\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(36p) .
Abstract\(hyerror Clause
_
.T&
lw(90p) | cw(36p) .
T{
Submission\(hycontrol\(hyviolated
T} 8.2.2.1\
.T&
lw(90p) | cw(36p) .
T{
Element\(hyof\(hyservice\(hynot\(hysubscribed
T} 8.2.2.2\
.T&
lw(90p) | cw(36p) .
Originator\(hyinvalid 8.2.2.4\
.T&
lw(90p) | cw(36p) .
T{
Recipient\(hyimproperly\(hyspecified
T} 8.2.2.5\
.T&
lw(90p) | cw(36p) .
Inconsistent\(hyrequest 8.2.2.7\
.T&
lw(90p) | cw(36p) .
Security\(hyerror 8.2.2.8\
.T&
lw(90p) | cw(36p) .
T{
Unsupported\(hycritical\(hyfunction
T} 8.2.2.9\
.T&
lw(90p) | cw(36p) .
Remote\(hybind\(hyerror 8.2.2.10
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 6/X.411 [T6.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.2.1.2
\fIProbe\(hysubmission\fR
.sp 9p
.RT
.PP
The probe\(hysubmission abstract\(hyoperation enables an MTS\(hyuser to
submit a probe in order to determine whether or not a message (the
subject\(hymessage) could be transferred and delivered to one or more recipient
MTS\(hyusers if it were to be submitted.
.PP
Success of a probe does not guarantee that a subsequently submitted
message can actually be delivered but rather that, currently, the recipient
is valid and the message would encounter no major obstacles to delivery.
.PP
For any \fBrecipient\(hynames\fR that denote a DL, the probe\(hysubmission
abstract\(hyoperation determines whether expansion of the specified DL
(but not of any nested DLs) would occur.
.PP
For any \fBrecipient\(hynames\fR for which redirection would occur, the
probe\(hysubmission abstract\(hyoperation determines whether the message
could be
transferred and delivered to the alternate\(hyrecipient.
.PP
The MTS\(hyuser supplies most of the arguments used for
message\(hysubmission and the length of the content of the subject\(hymessage.
The
probe\(hysubmission abstract\(hyoperation does not culminate in delivery to the
intended recipients of the subject\(hymessage, but establishes whether
or not the message\(hysubmission abstract\(hyoperation would be likely
to do so.
.PP
The successful completion of the abstract\(hyoperation signifies that the
MTS has agreed to undertake the probe (but not that it has yet performed
the
probe).
.PP
The disruption of the abstract\(hyoperation by an abstract\(hyerror
indicates that the MTS cannot undertake the probe.
.RT
.sp 1P
.LP
8.2.1.2.1\ \ \fIArguments\fR
.sp 9p
.RT
.PP
Table 7/X.411 lists the arguments of the probe\(hysubmission
abstract\(hyoperation, and for each argument qualifies its presence and
identifies the clause in which the argument is defined.
.RT
.sp 1P
.LP
8.2.1.2.1.1\ \
\fIProbe\(hyorigin\(hyauthentication\(hycheck\fR
.sp 9p
.RT
.PP
This argument provides any MTA through which the probe is
transferred, with a means of authenticating the origin of the probe (to
provide the probe origin authentication element\(hyofservice as defined
in
Recommendation\ X.400). It may be generated by the originator of the probe.
.PP
The \fBprobe\(hyorigin\(hyauthentication\(hycheck\fR provides proof of
the origin of the probe (Probe Origin Authentication), and proof of association
between
the \fBmessage\(hysecurity\(hylabel\fR and the \fBcontent\(hyidentifier\fR
of the
subject\(hymessage.
.PP
The \fBprobe\(hyorigin\(hyauthentication\(hycheck\fR is computed using the
algorithm identified by the \fBprobe\(hyorigin\(hyauthentication\(hyalgorithm\(hyidentifier\fR
(an \fBalgorithm\(hyidentifier\fR ).
.bp
.RT
.ce
\fBH.T. [T7.411]\fR
.ce
TABLE\ 7/X.411
.ce
\fBProbe\(hysubmission arguments\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(114p) | cw(30p) | cw(36p) .
Argument Presence Clause
_
.T&
lw(114p) | lw(30p) | lw(36p) .
\fIOriginator argument\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
Originator\(hyname M 8.2.1.1.1.1\
.T&
lw(114p) | lw(30p) | lw(36p) .
\fIRecipient arguments\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
Recipient\(hyname M 8.2.1.1.1.2\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Alternate\(hyrecipient\(hyallowed
T} O 8.2.1.1.1.3\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Recipient\(hyreassignment\(hyprohibited
T} O 8.2.1.1.1.4\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Originator\(hyrequested\(hyalternate\(hyrecipient
T} O 8.2.1.1.1.5\
.T&
lw(114p) | cw(30p) | cw(36p) .
DL\(hyexpansion\(hyprohibited O 8.2.1.1.1.6\
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIConversion arguments\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Implicit\(hyconversion\(hyprohibited
T} O 8.2.1.1.1.9\
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Conversion\(hywith\(hyloss\(hyprohibited
T} O 8.2.1.1.1.10
.T&
lw(114p) | cw(30p) | cw(36p) .
Explicit\(hyconversion O 8.2.1.1.1.11
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIDelivery method argument\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Requested\(hydelivery\(hymethod
T} O 8.2.1.1.1.14
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIPhysical delivery argument\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Physical\(hyrendition\(hyattributes
T} O 8.2.1.1.1.20
.T&
lw(114p) | lw(30p) | lw(36p) .
T{
\fIReport request argument\fR
T}
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Originator\(hyreport\(hyrequest
T} M 8.2.1.1.1.22
.T&
lw(114p) | lw(30p) | lw(36p) .
\fISecurity arguments\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
Originator\(hycertificate O 8.2.1.1.1.25
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Probe\(hyorigin\(hyauthentication\(hycheck
T} O 8.2.1.2.1.1\
.T&
lw(114p) | cw(30p) | cw(36p) .
Message\(hysecurity\(hylabel O 8.2.1.1.1.30
.T&
lw(114p) | lw(30p) | lw(36p) .
\fIContent arguments\fR
.T&
lw(114p) | cw(30p) | cw(36p) .
T{
Original\(hyencoded\(hyinformation\(hytypes
T} O 8.2.1.1.1.33
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hytype M 8.2.1.1.1.34
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hyidentifier O 8.2.1.1.1.35
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hycorrelator O 8.2.1.1.1.36
.T&
lw(114p) | cw(30p) | cw(36p) .
Content\(hylength O 8.2.1.2.1.2\
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 7/X.411 [T7.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 4
.PP
The \fBprobe\(hyorigin\(hyauthentication\(hycheck\fR contains the
\fBprobe\(hyorigin\(hyauthentication\(hyalgorithm\(hyidentifier\fR , and
an asymmetrically
encrypted, hashed version of the
\fBprobe\(hyorigin\(hyauthentication\(hyalgorithm\(hyidentifier\fR , and the
\fBcontent\(hyidentifier\fR and \fBmessage\(hysecurity\(hylabel\fR of the
subject\(hymessage.
Optional components are included in the \fBprobe\(hyorigin\(hyauthentication\(hycheck\fR
if they are present in the probe.
.PP
Future versions of this Recommendation may define other forms of
\fBprobe\(hyorigin\(hyauthentication\(hycheck\fR (e.g., based on
symmetric\(hyencryption\(hytechniques) which may be used by\ MTAs through
which the
probe is transferred to authenticate the origin of the probe.
.bp
.RT
.sp 1P
.LP
8.2.1.2.1.2\ \ \fIContent\(hylength\fR
.sp 9p
.RT
.PP
This argument specifies the length, in octets, of the \fBcontent\fR of
the subject\(hymessage. It may be generated by the originator of the
probe.
.RT
.sp 1P
.LP
8.2.1.2.2\ \ \fIResults\fR
.sp 9p
.RT
.PP
Table 8/X.411 lists the results of the probe\(hysubmission
abstract\(hyoperation, and for each result qualifies its presence and identifies
the clause in which the result is defined.
.RT
.ce
\fBH.T. [T8.411]\fR
.ce
TABLE\ 8/X.411
.ce
\fBProbe\(hysubmission results\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(36p) .
Result Presence Clause
_
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Probe\(hysubmission\(hyidentifier
T} M 8.2.1.2.2.1\
.T&
lw(90p) | cw(30p) | cw(36p) .
Probe\(hysubmission\(hytime M 8.2.1.2.2.2\
.T&
lw(90p) | cw(30p) | cw(36p) .
Content\(hyidentifier C 8.2.1.1.1.35
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 8/X.411 [T8.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.2.1.2.2.1\ \ \fIProbe\(hysubmission\(hyidentifier\fR
.sp 9p
.RT
.PP
This result contains an \fBMTS\(hyidentifier\fR that uniquely and
unambiguously identifies the probe\(hysubmission. It shall be generated by
the\ MTS.
.PP
The MTS provides the \fBprobe\(hysubmission\(hyidentifier\fR when notifying
the MTS\(hyuser, via the report\(hydelivery abstract\(hyoperation, of its
ability or
otherwise to deliver the subject\(hymessage.
.RT
.sp 1P
.LP
8.2.1.2.2.2\ \ \fIProbe\(hysubmission\(hytime\fR
.sp 9p
.RT
.PP
This result indicates the \fBtime\fR at which the MTS agreed to
undertake the probe. It shall be generated by the\ MTS.
.RT
.sp 1P
.LP
8.2.1.2.3\ \ \fIAbstract\(hyerrors\fR
.sp 9p
.RT
.PP
Table 9/X.411 lists the abstract\(hyerrors that may disrupt the
probe\(hysubmission abstract\(hyoperation, and for each abstract\(hyerror
identifies the clause in which the abstract\(hyerror is defined.
.RT
.ce
\fBH.T. [T9.411]\fR
.ce
TABLE\ 9/X.411
.ce
\fBProbe\(hysubmission abstract\(hyerrors\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(36p) .
Abstract\(hyerror Clause
_
.T&
lw(90p) | cw(36p) .
T{
Submission\(hycontrol\(hyviolated
T} 8.2.2.1\
.T&
lw(90p) | cw(36p) .
T{
Element\(hyof\(hyservice\(hynot\(hysubscribed
T} 8.2.2.2\
.T&
lw(90p) | cw(36p) .
Originator\(hyinvalid 8.2.2.4\
.T&
lw(90p) | cw(36p) .
T{
Recipient\(hyimproperly\(hyspecified
T} 8.2.2.5\
.T&
lw(90p) | cw(36p) .
Inconsistent\(hyrequest 8.2.2.7\
.T&
lw(90p) | cw(36p) .
Security\(hyerror 8.2.2.8\
.T&
lw(90p) | cw(36p) .
T{
Unsupported\(hycritical\(hyfunction
T} 8.2.2.9\
.T&
lw(90p) | cw(36p) .
Remote\(hybind\(hyerror 8.2.2.10
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 9/X.411 [T9.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
8.2.1.3
\fICancel\(hydeferred\(hydelivery\fR
.sp 9p
.RT
.PP
The cancel\(hydeferred\(hydelivery abstract\(hyoperation enables an MTS\(hyuser
to abort the deferred\(hydelivery of a message previsouly submitted via
the
message\(hysubmission abstract\(hyoperation.
.PP
The MTS\(hyuser identifies the message whose delivery is to be cancelled
by means of the \fBmessage\(hysubmission\(hyidentifier\fR returned by the\
MTS as a result of the previous invocation of the message\(hysubmission
abstract\(hyoperation.
.PP
The successful completion of the abstract\(hyoperation signifies that
the\ MTS has cancelled the deferred\(hydelivery of the message.
.PP
The disruption of the abstract\(hyoperation by an abstrar\(hyerror indicates
that the deferred\(hydelivery cannot be cancelled. The deferred\(hydelivery
of a
message cannot be cancelled if the message has already been progressed for
delivery and/or transfer within the\ MTS. The\ MTS may refuse to cancel the
deferred\(hydelivery of a message if the\ MTS provided the originator of the
message with \fBproof\(hyof\(hysubmission\fR .
.RT
.sp 1P
.LP
8.2.1.3.1\ \ \fIArguments\fR
.sp 9p
.RT
.PP
Table 10/X.411 lists the arguments of the cancel\(hydeferred\(hydelivery
abstract\(hyoperation, and for each argument qualifies its presence and
identifies the clause in which the argument is defined.
.RT
.ce
\fBH.T. [T10.411]\fR
.ce
TABLE\ 10/X.411
.ce
\fBCancel\(hydeferred\(hydelivery arguments\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(36p) .
Argument Presence Clause
_
.T&
lw(90p) | lw(30p) | lw(36p) .
\fISubmission argument\fR
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Message\(hysubmission\(hyidentifier
T} M 8.2.1.3.1.1
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 10/X.411 [T10.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.2.1.3.1.1\ \
\fIMessage\(hysubmission\(hyidentifier\fR
.sp 9p
.RT
.PP
This argument contains the \fBmessage\(hysubmission\(hyidentifier\fR of
the message whose deferred\(hydelivery is to be cancelled. It shall be
suppled by the MTS\(hyuser.
.PP
The \fBmessage\(hysubmission\(hyidentifier\fR (an \fBMTS\(hyidentifier\fR
) is that
returned by the MTS as a result of a previous invocation of the
message\(hysubmission abstract\(hyoperation (see \(sc\ 8.2.1.1.2.1), when
the message was submitted for deferred\(hydelivery.
.RT
.sp 1P
.LP
8.2.1.3.2\ \ \fIResults\fR
.sp 9p
.RT
.PP
The cancel\(hydeferred\(hydelivery abstract\(hyoperation returns an emply
result as indication of success.
.RT
.sp 1P
.LP
8.2.1.3.3\ \ \fIAbstract\(hyerrors\fR
.sp 9p
.RT
.PP
Table 11/X.411 lists the abstract\(hyerrors that may disrupt the
cancel\(hydeferred\(hydelivery abstract\(hyoperation, and for each abstract\(hyerror
identifies the clause in which the abstract\(hyerror is defined.
.RT
.ce
\fBH.T. [T11.411]\fR
.ce
TABLE\ 11/X.411
.ce
\fBCancel\(hydeferred\(hydelivery abstract\(hyerrors\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(36p) .
Abstract\(hyerror Clause
_
.T&
lw(90p) | cw(36p) .
T{
Deferred\(hydelivery\(hycancellation\(hyrejected
T} 8.2.2.3\
.T&
lw(90p) | cw(36p) .
T{
Message\(hysubmission\(hyidentifier\(hyinvalid
T} 8.2.2.6\
.T&
lw(90p) | cw(36p) .
Remote\(hybind\(hyerror 8.2.2.10
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 11/X.411 [T11.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
8.2.1.4
\fISubmission\(hycontrol\fR
.sp 9p
.RT
.PP
The submission\(hycontrol abstract\(hyoperation enables the MTS to
temporarily limit the submission\(hyport abstract\(hyoperations that the
MTS\(hyuser may invoke, and the messages that the MTS\(hyuser may submit
to the\ MTS via the
Message\(hysubmission abstract\(hyoperation.
.PP
The MTS\(hyuser should hold until a later time, rather than abandon,
abstract\(hyoperations and messages presently forbidden.
.PP
The successful completion of the abstract\(hyoperation signifies that the
specified controls are now in force. These controls supersede any previously
in force, and remain in effect until the association is released or the\
MTS
re\(hyinvokes the submission\(hycontrol abstract\(hyoperation.
.PP
The abstract\(hyoperation returns and indication of any
abstract\(hyoperations that the MTS\(hyuser would invoke, or any message
types that the MTS\(hyuser would submit, were it not for the prevailing
controls.
.RT
.sp 1P
.LP
8.2.1.4.1\ \ \fIArguments\fR
.sp 9p
.RT
.PP
Table 12/X.411 lists the arguments of the submission\(hycontrol
abstract\(hyoperation, and for each argument qualifies its presence and
identifies the clause in which the argument is defined.
.RT
.ce
\fBH.T. [T12.411]\fR
.ce
TABLE\ 12/X.411
.ce
\fBSubmission\(hycontrol arguments\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(36p) .
Argument Presence Clause
_
.T&
lw(90p) | lw(30p) | lw(36p) .
T{
\fISubmission control arguments\fR
T}
.T&
lw(90p) | cw(30p) | cw(36p) .
Restrict O 8.2.1.4.1.1
.T&
lw(90p) | cw(30p) | cw(36p) .
Permissible\(hyoperations O 8.2.1.4.1.2
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Permissible\(hylowest\(hypriority
T} O 8.2.1.4.1.3
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Permissible\(hymaximum\(hycontent\(hylength
T} O 8.2.1.4.1.4
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Permissible\(hysecurity\(hycontext
T} O 8.2.1.4.1.5
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 12/X.411 [T12.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.2.1.4.1.1\ \ \fIRestrict\fR
.sp 9p
.RT
.PP
This argument indicates whether the controls on submission\(hyport
abstract\(hyoperations are to be updates or removed. It may be generated by
the\ MTS.
.PP
This argument may have one of the following values:
.RT
.LP
\(em
\fBupdate\fR : the other arguments update the prevailing
controls;
.LP
\(em
\fBremove\fR : all controls are to be removed; the other arguments are
to be ignored.
.PP
In the absence of this argument, the defauld \fBupdate\fR shall be
assumed.
.sp 1P
.LP
8.2.1.4.1.2\ \
\fIPermissible\(hyoperations\fR
.sp 9p
.RT
.PP
This argument indicates the abstract\(hyoperations that the MTS\(hyuser
may invoke on the\ MTS.
.PP
This argument may have the value \fBallowed\fR or \fBprohibited\fR for
each of the following:
.RT
.LP
\(em
\fBmessage\(hysubmission\fR : the MTS\(hyuser may/may not invoke the
message\(hysubmission abstract\(hyoperation; and
.LP
\(em
\fBprobe\(hysubmission\fR : the MTS\(hyuser may/may not invoke the
probe\(hysubmission abstract\(hyoperation.
.PP
Other submission\(hyport abstract\(hyoperations are not subject to
controls, and may be invoked at any time.
.PP
In the absence of this argument, the abstract\(hyoperation that the
MTS\(hyuser may invoke on the\ MTS are unchanged. If no previous controls
are in
force, the MTS\(hyuser may invoke both the message\(hysubmission abstract\(hyoperation
and the probe\(hysubmission abstract\(hyoperation.
.bp
.RT
.sp 1P
.LP
8.2.1.4.1.3\ \ \fIPermissible\(hylowest\(hypriority\fR
.sp 9p
.RT
.PP
This argument contains the \fBpriority\fR of the lowest priority
message that the MTS\(hyuser shall submit to the\ MTS via the message\(hysubmission
abstract\(hyoperation. It may be generated by the\ MTS.
.PP
This argument may have one of the following values of the \fBpriority\fR
argument of the message\(hysubmission abstract\(hyoperation: \fBnormal,
non\(hyurgent\fR or \fBurgent\fR
.PP
In the absence of this argument, the \fBpriority\fR of the lowest priority
message that the MTS\(hyuser shall submit to the\ MTS is unchanged. If
no previous controls are in force, the MTS\(hyuser may submit messages
of any priority.
.RT
.sp 1P
.LP
8.2.1.4.1.4\ \ \fIPermissible\(hymaximum\(hycontent\(hylength\fR
.sp 9p
.RT
.PP
This argument contains the \fBcontent\(hylenght\fR , in octets, of the
longest\(hycontent message that the MTS\(hyuser shall submit to the\ MTS
via the
message\(hysubmission abstract\(hyoperation. It may be generated by the\ MTS.
.PP
In the absence of this argument, the
\fBpermissible\(hymaximum\(hycontent\(hylength\fR of a message that the
MTS\(hyuser may submit to the\ MTS is unchanged. If no previous controls
are in force, the content
length is not explicitly limited.
.RT
.sp 1P
.LP
8.2.1.4.1.5\ \ \fIPermissible\(hysecurity\(hycontext\fR
.sp 9p
.RT
.PP
This argument temporarily limits the sensitivity of submission\(hyport
abstract\(hyoperations (submission\(hysecurity\(hycontext) that the MTS\(hyuser
may invoke on the\ MTS. It is a temporary restriction of the \fBsecurity\(hycontext\fR
established when the association was initiated (see \(sc\ 8.1.1.1.1.3).
It may be generated by the\ MTS.
.PP
The \fBpermissible\(hysecurity\(hycontext\fR comprises one or more
\fBsecurity\(hylabels\fR from the set of \fBsecurity\(hylabels\fR established
as the
\fBsecurity\(hycontext\fR when the association was established.
.PP
In the absence of this argument, the \fBsecurity\(hycontext\fR of
submission\(hyport abstract\(hyoperations is unchanged.
.RT
.sp 1P
.LP
8.2.1.4.2\ \ \fIResults\fR
.sp 9p
.RT
.PP
Table 13/X.411 lists the results of the submission\(hycontrol
abstract\(hyoperation, and for each result qualifies its presence and identifies
the clause in which the result is defined.
.RT
.ce
\fBH.T. [T13.411]\fR
.ce
TABLE\ 13/X.411
.ce
\fBSubmission\(hycontrol results\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(36p) .
Result Presence Clause
_
.T&
lw(90p) | lw(30p) | lw(36p) .
T{
\fI\*QWaiting\*U results\fR
T}
.T&
lw(90p) | cw(30p) | cw(36p) .
Waiting\(hyoperations O 8.2.1.4.2.1
.T&
lw(90p) | cw(30p) | cw(36p) .
Waiting\(hymessages O 8.2.1.4.2.2
.T&
lw(90p) | cw(30p) | cw(36p) .
T{
Waiting\(hyencoded\(hyinformation\(hytypes
T} O 8.2.1.4.2.3
.T&
lw(90p) | cw(30p) | cw(36p) .
Waiting\(hycontent\(hytypes O 8.2.1.4.2.4
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 13/X.411 [T13.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.2.1.4.2.1\ \ \fIWaiting\(hyoperations\fR
.sp 9p
.RT
.PP
This result indicates the abstract\(hyoperations being held by the
MTS\(hyuser, and that the MTS\(hyuser would invoke on the\ MTS if it were
not for the prevailing controls. It may be generated by the MTS\(hyuser.
.PP
This result may have the value \fBholding\fR or \fBnot\(hyholding\fR for
each of the following:
.RT
.LP
\(em
\fBmessage\(hysubmission\fR : the MTS user is/is not holding
messages, and would invoke the message\(hysubmission abstract\(hyoperation
on the\ MTS if it were not for the prevailing controls; and
.LP
\(em
\fBprobe\(hysubmission\fR : the MTS\(hyuser is/is not holding probes,
and would invoke the probe\(hysubmission abstract\(hyoperation on
the\ MTS if it were not for the prevailing controls.
.PP
In the absence of this result, it may be assumed that the MTS\(hyuser is
not holding any messages or probes for submission to the\ MTS due to the
prevailing controls.
.bp
.sp 1P
.LP
8.2.1.4.2.2\ \
\fIWaiting\(hymessages\fR
.sp 9p
.RT
.PP
This result indicates the kind of messages the MTS\(hyuser is holding for
submission to the\ MTS, and would submit via the message\(hysubmission
abstract\(hyoperation, if it were not for the prevailing controls. It may be
generated by the MTS\(hyuser.
.PP
This result may have one or more of the following values:
.RT
.LP
\(em
\fBlong\(hycontent\fR : the MTS\(hyuser has messages held for submission
to the\ MTS which exceed the \fBpermissible\(hymaximum\(hycontent\(hylength\fR
control currently in force;
.LP
\(em
\fBlow\(hypriority\fR : the MTS\(hyuser has messages held for submission
to the\ MTS of a lower \fBpriority\fR than the \fBpermissible\(hylowest\(hypriority\fR
control currently in force;
.LP
\(em
\fBother\(hysecurity\(hylabels\fR : the MTS\(hyuser has messages held
for submission to the\ MTS bearing \fBmessage\(hysecurity\(hylabels\fR
other
than those permitted by the current security\(hycontext.
.PP
In the absence of this result, it may be assumed that the MTS\(hyuser is
not holding any messages or probes for submission to the\ MTS due to the
\fBpermissible\(hymaximum\(hycontent\(hylength\fR , \fBpermissible\(hylowest\(hypriority\fR
or
\fBpermissible\(hysecurity\(hycontext\fR controls currently in force.
.sp 1P
.LP
8.2.1.4.2.3\ \ \fIWaiting\(hyencoded\(hyinformation\(hytypes\fR
.sp 9p
.RT
.PP
This result indicates the \fBencoded\(hyinformation\(hytypes in the\fR
\fBcontent\fR of any messages held by the MTS\(hyuser for submission to
the\ MTS due to prevailing controls. It may be generated by the MTS\(hyuser.
.PP
In the absence of this result, the \fBencoded\(hyinformation\(hytypes\fR
of any messages held by the MTS\(hyuser for submission to the\ MTS are
\fBunspecified\fR .
.RT
.sp 1P
.LP
8.2.1.4.2.4\ \ \fIWaiting\(hycontent\(hytypes\fR
.sp 9p
.RT
.PP
This result indicates the \fBcontent\(hytypes\fR of any messages held by
the MTS\(hyuser for submission to the\ MTS due to prevailing controls.
It may be
generated by the MTS\(hyuser.
.PP
In the absence of this result, the \fBcontent\(hytypes\fR of any messages
held by the MTS\(hyuser for submission to the\ MTS are unspecified.
.RT
.sp 1P
.LP
8.2.1.4.3\ \ \fIAbstract\(hyerrors\fR
.sp 9p
.RT
.PP
Table 14/X.411 lists the abstract\(hyerrors that may disrupt the
submission\(hycontrol abstract\(hyoperation, and for each abstract\(hyerror
identifies the clause in which the abstract\(hyerror is defined.
.RT
.ce
\fBH.T. [T14.411]\fR
.ce
TABLE\ 14/X.411
.ce
\fBSubmission\(hycontrol abstract\(hyerrors\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(36p) .
Abstract\(hyerror Clause
_
.T&
lw(90p) | cw(36p) .
Security\(hyerror 8.2.2.8\
.T&
lw(90p) | cw(36p) .
Remote\(hybind\(hyerror 8.2.2.10
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 14/X.411 [T14.411], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
8.2.2
\fIAbstract\(hyerrors\fR
.sp 9p
.RT
.PP
This section defines the following submission\(hyport
abstract\(hyerrors:
.RT
.LP
a)
submission\(hycontrol\(hyviolated
.LP
b)
element\(hyof\(hyservice\(hynot\(hysubscribed
.LP
c)
deferred\(hydelivery\(hycancellation\(hyrejected
.LP
d)
originator\(hyinvalid
.LP
e)
recipient\(hyimproperly\(hyspecified
.LP
f
)
message\(hysubmission\(hyidentifier\(hyinvalid
.LP
g)
inconsistent\(hyrequest
.LP
h)
security\(hyerror
.LP
i)
unsupported\(hycritical\(hyfunction
.LP
j)
remote\(hybind\(hyerror.
.bp
.sp 1P
.LP
8.2.2.1
\fISubmission\(hycontrol\(hyviolated\fR
.sp 9p
.RT
.PP
The submission\(hycontrol\(hyviolated abstract\(hyerror reports the
violation by the MTS\(hyuser of a control on submission\(hyport services
imposed by the\ MTS via the submission\(hycontrol service.
.PP
The submission\(hycontrol\(hyviolated abstract\(hyerror has no
parameters.
.RT
.sp 1P
.LP
8.2.2.2
\fIElement\(hyof\(hyservice\(hynot\(hysubscribed\fR
.sp 9p
.RT
.PP
The element\(hyof\(hyservice\(hynot\(hysubscribed service reports that the
requested abstract\(hyoperation cannot be provided by the\ MTS because
the MTS\(hyuser has not subscribed to one of the elements\(hyof\(hyservice
the request requires.
.PP
The element\(hyof\(hyservice\(hynot\(hysubscribed abstract\(hyerror has no
parameters.
.RT
.sp 1P
.LP
8.2.2.3
\fIDeferred\(hydelivery\(hycancellation\(hyrejected\fR
.sp 9p
.RT
.PP
The deferred\(hydelivery\(hycancellation\(hyrejected abstract\(hyerror
reports that the\ MTS cannot cancel the deferred\(hydelivery of a message,
either because the message has already been progressed for transfer and/or
delivery, or
because the\ MTS had provided the originator with \fBproof\(hyof\(hysubmission\fR
.
.PP
The deferred\(hydelivery\(hycancellation\(hyrejected abstract\(hyerror has no
parameters.
.RT
.sp 1P
.LP
8.2.2.4
\fIOriginator\(hyinvalid\fR
.sp 9p
.RT
.PP
The originator\(hyinvalid abstract\(hyerror reports that the message or
probe cannot be submitted because the originator is incorrectly identified.
.PP
The originator\(hyinvalid abstract\(hyerror has no parameters.
.RT
.sp 1P
.LP
8.2.2.5
\fIRecipient\(hyimproperly\(hyspecified\fR
.sp 9p
.RT
.PP
The recipient\(hyimproperly\(hyspecified abstract\(hyerror reports that
the message or probe cannot be submitted because one or more recipients
are
improperly specified.
.PP
The recipient\(hyimproperly\(hyspecified abstract\(hyerror has the following
parameters, generated by the\ MTS.
.RT
.LP
\(em
\fBimproperly\(hyspecified\(hyrecipients\fR : the improperly specified
\fBrecipient\(hyname(s)\fR .
.sp 1P
.LP
8.2.2.6
\fIMessage\(hysubmission\(hyidentifier\(hyinvalid\fR
.sp 9p
.RT
.PP
The message\(hysubmission\(hyidentifier\(hyinvalid abstract\(hyerror reports
that the deferred\(hydelivery of a message cannot be cancelled because the
specified \fBmessage\(hysubmission\(hyidentifier\fR is invalid.
.PP
The message\(hysubmission\(hyidentifier\(hyinvalid abstract\(hyerror has no
parameters.
.RT
.sp 1P
.LP
8.2.2.7
\fIInconsistent\(hyrequest\fR
.sp 9p
.RT
.PP
The inconsistent\(hyrequest abstract\(hyerror reports that the requested
abstract\(hyoperation cannot be provided by the\ MTS because the MTS\(hyuser
has made an inconsistent request.
.PP
The inconsistent\(hyrequest abstract\(hyerror has no parameters.
.RT
.sp 1P
.LP
8.2.2.8
\fISecurity\(hyerror\fR
.sp 9p
.RT
.PP
The security\(hyerror abstract\(hyerror reports that the requested
abstract\(hyoperation could not be provided by the\ MTS because it would
violate
the security\(hypolicy in force.
.PP
The security\(hyerror abstract\(hyerror has the following parameters,
generated by the\ MTS:
.RT
.LP
\(em
\fBsecurity\(hyproblem\fR : an identifier for the cause of the
violation of the security\(hypolicy.
.sp 1P
.LP
8.2.2.9
\fIUnsupported\(hycritical\(hyfunction\fR
.sp 9p
.RT
.PP
The unsupported\(hycritical\(hyfunction abstract\(hyerror reports that an
argument of the abstract\(hyoperation was marked as \fBcritical\(hyfor\(hysubmission\fR
(see \(sc\ 9.1) but is unsupported by the\ MTS.
.PP
The unsupported\(hycritical\(hyfunction abstract\(hyerror has no
parameters.
.RT
.sp 1P
.LP
8.2.2.10\ \
\fIRemote\(hybind\(hyerror\fR
.sp 9p
.RT
.PP
The remote\(hybind\(hyerror abstract\(hyerror reports that the requested
abstract\(hyoperation cannot be provided by the\ MS because the\ MS is
unable to
bind to the\ MTS. Note that this abstract\(hyerror only occurs on indirect
submission to the\ MTS via an\ MS.
.PP
The remote\(hybind\(hyerror abstract\(hyerror has no parameters.
.RT
.LP
.bp